On Mon, 4 Apr 2005 10:20, C. Scott Ananian wrote:
Um, I'm fairly certain that rendezvous via any kernel synchronization mechanism (semaphores, condition variables, etc) will do exactly what you want. The blocked task goes to sleep and the rest of the time slice is preferentially transfered to the newly-active task.
I'm not sure where you got that from, but would appreciate any references. I know that a casual reading of some manual pages might suggest this, but that does not necessarily reflect the real in-kernel behaviour. The manual pages may mislead because it is not necessarily obvious to somebody who has not worked at the kernel level (or had the benefit of John Lyons' lecturing) that there is a difference between a process being "runnable" (ready to run or "awake"), and a process being in the "running" state (actually executing on a CPU). It also doesn't help that the "ps" command uses "R" for "runnable" and has no separate state indicator for "running".
The historical (UNIX) behaviour has always been that any processes waiting on the event merely gets woken when the event arrives, but that will only affect *whether* the process is considered for running, not *when*. The "when" part is normally "when the scheduler is good and ready" to run it.
If it were any different, a pair of conspiring threads would be able to starve the rest of the system (the directed yield/return to donor mechanism does not do that as the donee only gets time up until the original thread would have lost its time slice anyway).
I have not seen anywhere in the Linux kernel that behaves differently to this, and I can see nothing in the scheduler that causes or enables a determinative and immediate transfer of control to a particular thread.
On Mon, 4 Apr 2005 17:53, Andreas Mohr wrote:
AFAIR (some recent discussion?) there were good reasons for not implementing that, since it isn't all that helpful. But I'm not sure...
A reference to the discussion would be helpful - I can't find it by searching the ck list archive.
On Mon, 4 Apr 2005 17:55, Andreas Mohr wrote:
the main reason a direct yield is not implemented [is that] The usual blocking architecture achieves the same thing.
I think perhaps we are talking at cross purposes. In directed yield, the donor thread, which has access to the CPU until such time as it either yields or is pre-empted, donates that access directly to the donee thread. The donee thread immediately gets access to the CPU, and can return the CPU to the donor thread if it completes its task before the original thread would have been pre-empted. Ideally the time is charged to the donor rather than the donee.
As far as I can see, there is nothing in the 2.6 scheduler that does that.