Messages in this thread | | | Date | Sun, 16 May 1999 19:12:38 +0200 (MET DST) | From | Gerard Roudier <> | Subject | Re: Why 'wait queues' and not 'channels' |
| |
On Sun, 16 May 1999, David S. Miller wrote:
> Date: Sat, 15 May 1999 20:58:17 +0200 (MET DST) > From: Gerard Roudier <groudier@club-internet.fr> > > Linux waits on 'wait queues' but other UNIXes sleep on 'channels'. > > What is better with wait queues? > > Believe me when I say that we don't want the traditional sleeping > methodology of "UNIX" in any way shape or form.
I also donnot want it since it seems very broken to me.
> As far as I know, only Plan9 and Linux get the sleeping method correct > (someone please correct me if some other OS does things this way as > well).
Donnot know of Plan9, but AFAIK it has been invented by the inventors of traditionnal UNIX. ;-)
> Essentially the crucial difference is, under Linux we: > > add_to_wait_queue > while(1) { > check event, break if event happened > break if signal arrived > schedule(); > } > remove_from_wait_queue > > On first sight, you may think nothing interesting is happening here. > > Think harder, the issue is that we eliminate completely any races > between the adding to wait queue and test of the event. The task > himself controls completely his existence on the wait queue.
My opinion is that we got race conditions we deserve if we donnot lock when we should do so. The above code just enforces some ordering of operations using some locks or barriers that are not visible. It may be correct, but it is complex and relies to much on synchronisation done in our back.
Both the test of the condition and the entering to the SLEEP/WAIT/... on event/channel/... needs to be atomic. So any SLEEP/WAIT thing should only be entered with a LOCK in SMP (or with interrupt disable in UP), and it is the SLEEP/WAIT thing that will unlock the LOCK (or reenable interrupt) at a moment that avoid races.
For O/Ses that support SMP, any WAIT_ON_CHANNEL_ETC.. interface that does not require a LOCK as argument seems to me incorrect or just too complex to deal with. ;-)
> Other systems have a more complex issue about avoiding the race > between the test and the sleep (especially on SMP) because they have > only a "add to wait queue and schedule()" singular interface. > > I suggest not changing the wait queue architecture we have, it's done > right and cleanly.
It is perhaps correct in theory, but it pollutes most of kernel data structures with wait_queues. For example, what happens if we free a data structure with some not empty wait queue in it ?
By the way, I am unable to propose a good sleep/wakeup interface :), but I think that some much better must exist.
Regards, Gérard.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |