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

Re: mutex-owner

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.

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