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 `mutex-unlock!' procedure described in the SRFI accepts, as an optional second argument, a condition variable; if specified, the thread will atomically release the mutex and add itself to the condition variable. However, when the thread is awakened, it does not automatically re-acquire the mutex. In both the Java and POSIX thread interfaces, the operation for waiting on a condition variable (`wait' in Java and `pthread_cond_wait' in the POSIX thread API) automatically re-acquires the mutex for the thread when it is awakened. I can't see any reason this re-acquisition must necessarily be part of the waiting operation --- clearly, the awakened thread must wait its turn for the mutex, like everyone else. But I think it is easier to reason about: the invariant "I've got the mutex" holds upon entry and exit to the waiting operation --- just not while it's waiting. If this is a deliberate choice, it's an unusual one, and there should be some rationale given in the SRFI. If you decide to change the SRFI's waiting operation to more closely resemble those provided by the other systems, then I think it should be given its own name, instead of being attached to `mutex-unlock!' --- it would be odd indeed for a function named `mutex-unlock!' to return with the mutex still locked. `condition-variable-wait!' would be one possibility.