Wine device drivers proposal
wine at troy.rollo.name
Mon Apr 4 20:44:12 CDT 2005
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
As far as I can see, there is nothing in the 2.6 scheduler that does that.
More information about the wine-devel