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).

Marc