ANONYMOUS wrote:
> ....
> 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.
