"Lewei Xu" <23*0*0*
8@s*u*e*t*u*a*e*u*a*> wrote:
> 1. When time quantum = time of system call. At this point I am assuming it is intentional, that is, to move the process off running and run the system call at 0usecs the next time it is on the CPU. Logically (and intuitively), I believe the system call should occur first, but if this is how you want us to do it, I don't really mind. Just need some clarification on if this is actually how you want us to implement the time quantum.
Sorry, but I cannot understand your description or reasoning here.
I'm wondering if there's confusion because multiple 'things' are sometimes reported at happening at the same (integral) time?
For example, if a process has spent a 5 full usecs computing, and its TQ expires at the the end of that 5th usec, it cannot 'squeeze' a system-call into that same 5th usec.
Can you provide (the smallest) example - just state the TQ and give the command-file - that demonstrates your concern?
> 2. Timing is still off slightly. There is still an extra usec after a system call occurs. In the screenshot below, I believe 'spawn' should occur at t = 25. If this was intentional, could I please get confirmation so that I can also implement this in my own solution?
Unsure if this is the same possible misunderstanding. The transition from READY->RUNNING takes the full 5 usecs (21..25), at the end of that 25th usec the process is back on the CPU, and at the beginning of the 26th usec it gets to execute its spawn system-call. It cannot execute the system-call during the 25th usec, as the OS still owns the CPU until the end of that 25th usec. At the beginning of the 26th usec, the process now own the CPU and can continue its execution.