guile-devel
[Top][All Lists]
Advanced

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

Re: Recursive mutexes?


From: Neil Jerram
Subject: Re: Recursive mutexes?
Date: 26 Oct 2002 22:39:28 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

>>>>> "Marius" == Marius Vollmer <address@hidden> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]