I can’t figure out whether it was me who wrote the words “compute access” or whether it was meant be something else and was autocorrected into that. Either way, what I meant was that the scheduler would normally come around at some fixed time, say after 1 ms, and task switch to something else if it found that the original process was still executing. Instead of letting this happen, he paused execution at 0.99 ms and told the scheduler he was done with his work. Then, he immediately resumed the process, which caused the scheduler to return control back to him.
That's a pretty bad scheduler then because normally it would have moved that task to the tail of the 'ready' list for that particular priority level rather than to the front because it yielded voluntarily.
IIRC there are schedulers that dynamically adjust priority based on recent CPU usage. When a task is removed from the CPU due to its time quantum running out (as opposed to, say, making a blocking system call), that is taken as a sign that the task is relatively CPU-intensive, and its priority is reduced a little.
The idea is to give IO-bound tasks a little more priority in comparison. IO-bound tasks generally run faster if they can get another IO operation started ASAP after the last one completes, and since they're not going to hog the CPU anyway, giving them relatively higher priority is one way to do this.
Anyway, the point is that the trick works by gaming the system of priority levels. If you're at the tail of one priority level, you may be off than at the head of another.
I can't parse this; could you clarify? What exactly do you mean by "relinquish compute access right before anyone would check up on it"?