This page is part of the web mail archives of SRFI 21 from before July 7th, 2015. The new archives for SRFI 21 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). Marc