[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

spurious wakeup from waiting on a condition variable

This page is part of the web mail archives of SRFI 18 from before July 7th, 2015. The new archives for SRFI 18 contain all messages, not just those from before July 7th, 2015.

The semantics of (mutex-unlock! mutex condition-variable) currently
state that mutex-unlock! will only return when the condition-variable
has been signaled.  It turns out that this makes it very hard to
implement a mechanism for interrupting blocked threads so that they
perform some operation even if they are blocked (an extension to the
SRFI which Gambit-C uses when the scheduler needs to report scheduler
errors to the primordial thread).  Because an interrupted wait in
(mutex-unlock! mutex condition-variable) can't be restarted (because
a call to condition-variable-signal! during the interrupt would
go undetected), it is necessary to modify the semantics of
(mutex-unlock! mutex condition-variable) so that the wait can
end at any moment, and it is guaranteed that the wait will end
when condition-variable-signal! or condition-variable-broadcast! is
called.  Applications have to tolerate this (but this should
be natural since when a thread wakes up it typically verifies
if the condition has become true, and if not reenters a wait state).