Re: Recursive mutexes?

[Neil Jerram <neil@ossau.uklinux.net>]

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

    Marius> Our current coop mutexes are not 'recursive'.  This means that a
    Marius> thread blocks when it tries to lock a mutex that it already has
    Marius> locked.

    Marius> I think we should make our mutexes be recursive by default.  Expecting
    Marius> to block when locking a mutex that is already lcoked by one self is
    Marius> not very useful, since no one can unlock that mutex (excepts asyncs).

True, but a situation like this (the same thread trying to relock the
same mutex) can alert you to a programming error.  A dramatic problem
(the program hanging) is often more useful than the error being hidden.

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

IIRC, it's easy to implement a recursive mutex if you already have a
non-recursive one, but the reverse is not so easy.

    Marius> SRFI-18 specifies non-recursive mutexes and allows non-owning threads
    Marius> to unlock a mutex.

On first hearing, this sounds like it could be a useful feature.

    Marius> Such uses of a mutex are, in my view, a mockery of
    Marius> condition variables should be avoided.

I think you'll have to rephrase that! :-)

    Marius> If non-recursive mutexes turn out to be important, we can provide them
    Marius> as well, as an option.

I'm pretty sure they are important (enough), so I suggest that we
provide both.  What would be quite nice (and I think is possible)
would be to implement non-recursive mutexes in a
thread-implementation-specific way, and then recursive mutexes in a
generic way based on whatever non-recursive mutex is currently
configured.

        Neil



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