It's UWAweek 10 (1st semester, week 2)


This forum is provided to promote discussion amongst students enrolled in CITS2002 Systems Programming.
Please consider offering answers and suggestions to help other students! And if you fix a problem by following a suggestion here, it would be great if other interested students could see a short "Great, fixed it!"  followup message.
Displaying selected article
Showing 1 of 1168 articles.
Currently 3 other people reading this forum.

 UWA week 36 (2nd semester, mid-semester break) ↓
SVG not supported

Login to reply

9:58am Thu 7th Sep, Christopher M.

> .... > Then this is the confusing part for me is the 16th usecond an extra usecond for status change or is it included in the status change transition time. If it is the later then why does it specific starting from 17 and not 16th. If former why does only it take an extra usecond for status change only on this occasion and not any other time? > > Honestly all code would make sense if the 16th usecond was part of either the execution time or the sleep time.
Firstly, thanks for explaining your confusion/misunderstanding in such great detail, it helps to provide an answer knowing what you don't understand or what you've overlooked. What you and a number of other students have described as 'an extra usec' at 16usecs in your example is there to reflect the fact that something has to occur at t=16, and that it doesn't happen in zero time. At t=15 shortsleep is performing some calculation on (owns) the CPU, at t=16 shortsleep executes some instructions to call the OS to request that shortsleep be 'put to sleep', and at t=17..26 the OS now owns the CPU and executes instructions to save the state of shortsleep. The sleep 250 request at t=16 is not a single machine-level instruction. It requires the process to make a function-call into a system library by copying the parameter 250 to a known location (such as onto the stack or into a CPU register), saving the current instruction's location, and finally calling the library function - probably with the same name of sleep(). The sleep() library function checks that the parameter (250) is valid (here, simply non-negative) and, all being well, finally (on an x86 anyway) issues a software trap instruction to enter the OS kernel. Please review pages 2-5 of Lecture 10. Now, from t=17, the OS owns the CPU and can execute the instructions to save the state of shortsleep. In practice, making a function call and then a trap into the OS does not take a full usec, but it doesn't happen in zero time, either. We don't wish our project to be complicated by the fact that the process and the OS both might be doing something between 16.0 and 16.999999.. So we allocate all of t=16 to the process making the system call request by executing the library function (code still executed by the process, in user-space), and then from t=17 the OS is performing its work. ____ BUT, the problem is (was) not occurring at t=16, but at t=36 in your example. The sample solution was incorrectly storing the time the process would be sleeping, instead of when it would be (eligible) to be awoken. In your example, the 'wake up time' was being stored as 16+20 = 36 whereas it should have been 16+20+1 = 37, to reflect that the process doesn't commence sleeping at t=16 but at t=17. The sample now includes this correction (which just leaves the need to remove '..0026 idle' but that's just based on how it's reported) AND THEN, I'm very confused as to why your screenshot says 'sleep 250', when it should be 'sleep 20' (which is what is implemented). I cannot comprehend where the 250 comes from, or replicate it, when it should be/is 20.

The University of Western Australia

Computer Science and Software Engineering

CRICOS Code: 00126G
Written by [email protected]
Powered by history
Feedback always welcome - it makes our software better!
Last modified  5:07AM Sep 06 2023
Privacy policy