> In order to implement `mutex-owner' we need to be able to inspect the
> mutex.  If the implementation is based upon a non-custom threads
> library, such facilities may not be available.  For example, the POSIX
> threads interface doesn't provide it.
>
> I'm thus afraid that `mutex-owner' demands too much of the
> implementation.

But if the base implementation does not provide it, mutex-owner can be
implemented by representing each Scheme mutex by a lower-level mutex and
a condition variable.

So I agree that it is not a direct mapping to the lower-level threads,
but it is not overly inefficient or complex.

Mutex-owner is mostly useful for debugging purposes so you can tell
which thread is holding on to a mutex that never seems to unlock.

Note that there is another implementation problem: Scheme mutexes can
be unlocked by a different thread than the owner.  Some thread systems
don't support this (for example POSIX threads).  Fortunately, the
semantics of mutexes proposed can be implemented with a lower-level
mutex and a condition variable.  So supporting mutex-owner is not an
additional overhead.

Marc