[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> 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
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