lkml.org 
[lkml]   [1999]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: {interruptible_,}sleep_on question


On Mon, 1 Nov 1999, Manfred Spraul wrote:

> Is it correct that drivers which call {interruptible_,}sleep_on can miss
> wakeup events unless they either own the big kernel lock or the
> global-cli lock before calling sleep_on()?
>
> Normally, I would use the sequence
> * add_wait_queue
> * set_current_state(TASK_UNINTERRUPTIBLE)
> * check that you must wait, and that someone will wake you up.
> * schedule().
>
> If you use sleep_on(), then the sequence is
> * check that you must wait, and that someone will wake you up.
> * within sleep_on:
> add_wait_queue
> set_current_state(TASK_UNINTERRUPTIBLE)
> schedule().
>
> If this is really a problem, then (AFAICS) the DAC960 driver could lock
> up.

For sleep_on() to work reliably in SMP, it should accept a reference to
some lock that ensures that the test of the condition and the thread
sleeping are executed atomically. But may-be there are situations where we
know about the waker not being in race and sleep_on() then may be safe.
For UP, disabling interrupts does the trick.

Even the sequence that works does not seem fine to me, since it looks like
SMP synchronisation relying simply on memory ordering, and I cannot
beleive this to work in all situations and on any kind of hardwares and
architectures. Indeed it is not so, but I do prefer semantics that
explicitely refers to locks for SMP synchronisations.

Gérard.

> --
> Manfred
>
> -


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

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.111 / U:1.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site