Transcript Slide

Nachos Project 4
Lecturer: Hao-Hua Chu
TA: Chun-Po Wang
(Artoo)
Date: 2008/10/25
Project 4
• Design and implement
appropriate support for
multiprogramming
• Extend the system calls to handle
process management and interprocess communication primitives
2
Summary
• Motivation & Objective
• Problems
• Goal 1~7
– 1,2,7 10% 3+4 30% 5+6 20%
• Report
– 20%
• Submission
3
Motivation & Objective
• Nachos is currently an uniprogramming environment
• Alter Nachos so that each
process is maintained in its own
system thread
4
Problem
• Take care of memory allocation
and de-allocation
• Consider all the data and
synchronization dependencies
between threads.
5
Goal 1
• Alter your exceptions to finish the
thread instead of halting the
system.
• This will be important, as a run
time exception should not cause
the operating system to shut
down.
• Modify exception.cc
6
Goal 2
• Implement multiprogramming.
– The Nachos code is restricted to
running one user program at a time.
• In order to convert the system
from uni-programming to
multiprogramming.
• Modify addrspace.h,
addrspace.cc, and machine.h
7
Goal 2
• You will need to:
– A. Come up with a way of allocating
physical memory frames so that
multiple programs can be loaded
into memory at once.
– B. Properly handling freeing address
space when a user program finishes.
8
Goal 2
– C. It is very important to alter the
user program loader algorithm such
that it handles frames of information.
– Modify NumPhysPages (default 128)
variable in machine.h
• You are not required to deal with
limited memory space
9
Goal 3
• Create table to store ProcessID (an
integer)
• Implement the ProcessID Exec(char
*name) system call.
– Exec starts a new user program running
within a new system thread.
– Figure out how to set up user space inside
a system thread.
– Path name would be no longer than 256
bytes (including ‘\0’)
10
Goal 3
– Exec should return –1 on failure,
else it should return the “ProcessID”
of the user level program it just
created
– More like fork + exec in linux
– Execute in /build.linux
11
Goal 4
• Implement the int Join(ProcessID
id) and void Exit(int exitCode)
system calls.
– Join will wait and block on a
“Process ProcessID ” as noted in its
parameter.
– Exit returns an exit code to
whomever is doing a join.
• 0 if a program successfully completes,
12
another value if there is an error.
Goal 4
– The exit code parameter is set via
the exitCode parameter. Join
returns the exit code for the process
it is blocking on, -1 if the join fails.
– A user program can only join to
processes that are directly created
by the Exec system call.
• You can not join to other processes or
to yourself.
13
Goal 4
– You will have to use semaphores
inside your system calls to
coordinate Joining and Exiting user
processes.
14
Goal 5
• Implement the int
CreateSemaphore(char *name,
int semval) system call.
– Modify start.s and syscall.h to add
the new system call signatures.
– You will create a container at the
system level that can hold upto 10
named semaphores.
15
Goal 5
– The CreateSemaphore system call
will return 0 on success and –1 on
failure.
– The CreateSemaphore system call
will fail if there are not enough free
spots in the container, the name is
null, the other semaphore with the
same name already exists ,or the
initial semaphore value is less than
0.
16
Goal 6
• Implement int wait(char *name)
and int signal(char *name) system
calls.
– The name parameter is the name of
the semaphore.
17
Goal 6
– Both system calls return 0 on
success and –1 on failure.
– Failure can occur if the user gives
an illegal semaphore name (one
that has not been created).
18
Goal 7
• Sleeping Barber Problem is too
difficult (You have to create IPC)
• So Many Producers to Many
Consumers Problem is used to
replace.
• You have to implement two user
programs: Producer and
Consumer
19
Goal 7
• There are 3 kinds of resources:
– A, B, C
– Use semaphores named “A”, “B”,
”C” respectively
• Producer produce in a order: A, B,
C for 10 times
• Consumers consume in a order
C, B ,A for 10 times
20
Goal 7
• Producer will print its process ID
and resource he creates on
screen
• Consumer will print its process ID
and resource he consumes on
screen
• You have to create a system call
GetProcessID() to get process ID
21
in user program
Goal 7
• Use your Print(), PrintNum() to
print the output.
• Use semaphore to avoid
interruption during each user
program print its output for each
line which describes process
consumes or produces the
resource
22
Goal 7
• Output example:
– 1 produces A
– 2 produces A
– 1 produces B
– 1 produces C
– 3 consumes C
– 3 consumes B
23
Goal 7
• We will use your
CreateSemaphore to create three
semaphore with name “A”, “B”,
“C” to represent resource A, B, C
• Then use your Exec to call your
two kinds of user program (at
most 10 for each) for several time
to test your program
24
Report
• Write a 2-page report
– Don’t just paste your code, I’ll read it myself
– Explain why your implementations would
generate correct output
– Describe meaningful problems you
encountered and how you solved.
• If your project submission can’t compile and
execute on Linux in Workstation Room 217,
we will consider it as fail.
– Please contact me to apply a workstation account if
you need it.
25
Submission
•
Two people in one group (Write down the
name and student ID of all members in the
report)
The file you need to send:
•
1.
2.
•
A report in .pdf or .doc
All the Nachos directory
Send your files
–
Tar your files to an archieve
named: other files...
tar zcvf os_hw4_bXXXXXXXX_bOOOOOOOO.tar.gz
report.doc
–
–
os_hw4_bXXXXXXXX_bOOOOOOOO.tar.gz
E-mail to [email protected] with following
title:
[os_hw4] bXXXXXXXX_bOOOOOOOO
Please follow the format carefully or our autoreply system will not work
26
Submission (cont.)
• Deadline: 12/16 24:00
– For the delayed submission, deduct
5 points for each day
• DO NOT COPY!!
Protect your code well!!
27