> 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/