[Top][All Lists]
[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
Re: Recursive mutexes?, Rob Browning, 2002/10/26