Wine device drivers proposal

[Troy Rollo]

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.