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