TA in charge of this project: | Aaron Blankstein (ablankst@cs.princeton.edu) |
Lab TAs in charge of this project: | Amy Ousterhout (aousterh@princeton.edu) |
Leonardo Stedile (lstedile@princeton.edu) |
In this project, you will add the following functionality to the previous assignment's kernel. We recommend you tackle these problems in this order:
The source code is distributed with two test cases:
To select a test case, use the tasks script just like in project 3.
Processes will be able to communicate via first-in, first-out message box queues. These queues should be an efficient implementation of the bounded-buffer problem.
Message boxes support four operations, each with a corresponding system call:
You will write a handler for irq1. This handler will receive bytes from the keyboard, and buffer them using a message box. If the keyboard buffer is full, the handler must instead discard the character.
You must also implement the get_char system call. This system call will try to read a character from the keyboard buffer, or block until one is available.
To aid in your debugging, the initial code distribution contains a dummy implementation of get_char. This implementation repeatedly types out the strings:
The spawn() system call should create a new running process.
First, it must look up a process by name. Since we have not yet implemented file systems, you are provided a dummy filesystem defined in ramdisk.h. The test cases each define their own files.
You may assume a finite number of running processes (NUM_PCBS).
Return the pid on success, -1 if unable to find the process, -2 if there are too many processes.
The kill() system call should change the state of a process such that it will die (soon.) Special care must be taken in certain circumstances; for instance, there may be difficulties if this process is not in the ready queue. Think about this problem, and discuss your solution at design review.
When a process is killed, no effort should be made to release any resources that it holds (such as locks).
The kill system call should immediately kill a process, even if it is sleeping or blocked (even on a wait() call.). If a process is killed while sleeping, other sleeping processes should still wake on schedule. If a process is killed while blocked on a lock, semaphore, condition variable or barrier, the other processes which interact with that synchronization primitive should be unaffected. If a process is killed while it is in the ready queue, lottery scheduling should still give proportional scheduling to the surviving processes.
The wait() system call should block the caller until a given process has terminated. You implementation must be efficient.
Description | Points |
---|---|
Design review | 5 |
mbox send and receive correctly | 2 |
keyboard input handled correctly | 1 |
spawn correctly schedules a new process | 2 |
wait correctly blocks a task and wakes up on kill or exit | 1 |
kill correctly removes tasks without affecting others | 2 |
correctly reclaim of mboxen | 1 |
correctly reclaim PCBs | 1 |
Submit via dropbox (only one person should submit per group.) When you submit, you should submit at least a readme (less than 500 words) and the following files
If you have modified any files other than those listed above, or if you have created new files, you may submit those as well.
For 1 point of extra credit, modify your implementation of kill() so that any locks held by the killed process are released. You will need to write your own test case in which one process blocks on a lock held by another process that is eventually killed. You do not need to submit your test cases. If you do implement this, note this and describe your design in your readme.