Design and Coding
In this assignment you have three tasks to complete. Each is in some way orthogonal to the others, so you can work on them in any order.
Unlike prior assignments where there has been a good deal of guidance on how to proceed, in this assignment some of the work is more open-ended. You will need to think about how to implement the required functionality (and perhaps how to test it).
You are free to make changes anywhere in the OS/161 codebase to complete these tasks, so long as your changes are well considered and well documented. For example, you might decide to change the interface for a kernel function to take a new argument, or refactor some code to make it easier to add new functionality.
Your code and overall design will need to be documented in handin/design.md, which will be used to make the pull-request documentation that your peers will evaluate during patch peer review.
Task 1: Nanosleep
In the written questions, you identified some serious issues with the current implementation of nanosleep. Your task is to write a new implementation that addresses these issues.
There are multiple ways to accomplish this task, each with different trade-offs in terms of implementation complexity and performance. You should consider these trade-offs and document your reasoning in your code.
I recommend that you don't dive into coding this one right away. Instead, allow yourselves to mull over the problem and come up with a plan before you start coding. You can always talk to Prof. Melissa about your ideas.
Task 2: More Time Tracking
The kernel now reliably tracks user time and system time for each thread. But there are other timing statistics that might be interesting to track and report (and in particular, statistics that will be useful in measuring the impact of your scheduler changes in the next task).
Your task is to decide on one or two additional timing statistics to track, and to implement the tracking and reporting of those statistics. You should extend the struct rusage structure to include these new statistics, and add code to the shell to report them.
You can also go the extra mile and implement the getrusage system call to allow userland programs to access these statistics while they're running (rather than just at the end via wait4).
Task 3: Wake-at-Front
In the lessons on scheduling, we discussed the idea of wake-at-front, where threads that have been sleeping are placed at the front of the run queue when they wake up. This approach can help reduce the latency of threads that have been sleeping and is a simple way to enhance the OS/161 scheduler without implementing a full-blown priority system.
One concern with wake-at-front is that an adversarial program could create several children that wake and sleep rapidly, causing other processes to starve. Your task is to implement wake-at-front in a way that avoids starvation.
(When logged in, completion status appears here.)