Re: Recursive mutexes?

[Rob Browning <rlb@defaultvalue.org>]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Our current coop mutexes are not 'recursive'.  This means that a
> thread blocks when it tries to lock a mutex that it already has
> locked.
>
> I think we should make our mutexes be recursive by default.  Expecting
> to block when locking a mutex that is already lcoked by one self is
> not very useful, since no one can unlock that mutex (excepts asyncs).

Though people coming from POSIX threads (at least under glibc) will be
used to having to explicitly ask for recursive mutexes, and at least
at the C level, there's apparently an efficiency issue involved.
Would it be hard to provide both and let the user select at creation
time?

> The only good argument against recursive mutexes that I can think of
> is a tiny performance gain since you don't need to do some checking.

I guess to some extent it would depend on how tiny the gain would be :>

> SRFI-18 specifies non-recursive mutexes and allows non-owning threads
> to unlock a mutex.  Such uses of a mutex are, in my view, a mockery of
> condition variables should be avoided.

Well you certainly could use a condition variable instead of a mutex
here, but I would suspect that in cases where you just want to wake
someone else up, a mutex others can unlock would be lighter weight.
With a condition variable you have to have both a mutex and the
condition variable.

It sounds like the SRFI-18 mutexes are just POSIX Semaphores with one
token, and POSIX Semaphores are more flexible, and seem only trivially
harder to implement -- likely not much more than adding an integer
counter and a few trivial numeric comparisons.  If so, I'd rather have
a POSIX Semaphore and provide a trivial wrapper that satisfies
SRFI-18.

In POSIX mutexes are pretty low-level -- they're more or less just an
atomic lock -- that makes sense since they're the simplest portable
sync type.  Semaphores and Condition Variables are for anything more
than the most basic operations, and even there (as you and I talked
about), there are no FIFO fairness guarantees, so you're often faced
with building your own sync operations on top of them.

One thing that the POSIX model has going for it is exposure -- I
suspect a lot of people are familiar with how the API works, so my
default inclination would be to follow that API whenever there's not a
good reason not to.  We may also want to add some enhancements like
FIFO guarantees that don't contradict the standard, but that's a
separate question.

IMO thread programming is hard.  Writing correct algorithms using
threads can be hard, and if someone already has something they've
written using the POSIX semantics that works, it will be a lot easier
to migrate to another language if the semantics are similar.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel