HW5: Extensions to the Multitasking Kernel.

Added on - 18 Sep 2019

Trusted by +2 million users,
assist thousands of students everyday
Showing pages 1 to 1 of 2 pages
University of Massachusetts - BostonDr. Ronald CheungCS 444: Intro to Operating SystemsSpring 2019Homework AssignmentHW5: Extensions to the Multitasking KernelAssigned:30April 2019Due:16 May 20191.IntroductionThe objective of this assignment is to extend the multitasking kernel obtained in hw3 to include thepreemptive scheduler. Copy the files to your cs444/hw5 dir. Provide a README with guide to yoursources.2.Preemptive schedulerConvert the scheduler to be preemptive, and let process 0 run an idle loop at normal process level,preempted as necessary for the user processes. Of course this requires a clock ticking.1) You will need to set and run the system timer, the "PIT". An example of how to do this is in$pcex/timetest.c. The timer(or "clock") in timetest.c will take up to approximately 55 milliseconds torun down and cause an interrupt. Change it to interrupt every 10 ms, like Linux. When you first foldthis in, it will print a "." for every tick--leave that in for a while, to make sure it's ticking away, but takeout the dots before the final testing.2) Add a CPU quantum to each process. Use a quantum between 4x10 to 10x10 ms. Decrement it inthe tick handler and call schedule when it's gone. You should confirm that when there are two cpu boundprocesses, they alternate in execution. The preemptions of user processes are recorded in the debug_logand printed out at the end of the run along with the marks for input, output, and process-switch fromzombie.3) Keep counts of how much cpu each uprog uses and how many characters each outputs. To do thisadd appropriate fields to the proc structure. At each tick, increment the cpu field of the running process.Also, each time there is a successful enqueue, increment the output character count. Print the countswhen the whole program exits (that is, when you print the exit values).4) As a debugging tool add an int parameter to the scheduler function. Each call site to the schedulershould use a different integer for this parameter. (e.g. if there are 3 call sites, use 0, 1 and 2). Createan int array in the kernel data area whose size is the number of integers used. The idea is that when thescheduler is called from call site 0, you will increment the 0th element of the array by 1, when calledfrom call site 1, increment the 1st element, etc. Print output the accumulated values at the finish. Thiswill allow you to confirm that the scheduler is being called from the clock interrupt handler.There may be new race conditions in the kernel due to preemption in the kernel. For example,"number_of_zombie++" in sysexit needs protection unless we can prove it is implemented with just oneinstruction. Otherwise, between the two, there could be a preemption causing another process to run andexit, reading the old count. They both end up writing the same count, losing one increment. This iscalled the lost update problem. Most of the ++'s are acting on local variables-- these are process-privateand thus immune from such shared access.1
You’re reading a preview
Preview Documents

To View Complete Document

Become a Desklib Library Member.
Subscribe to our plans

Download This Document