Re: Recursive mutexes?

[Thomas Bushnell, BSG]

Marius Vollmer <address@hidden> writes:

> Neil Jerram <address@hidden> writes:
> 
> > >>>>> "Marius" == Marius Vollmer <address@hidden> writes:
> > 
> >     Marius> I think we should make our mutexes be recursive by
> >     Marius> default.  Expecting to block when locking a mutex that
> >     Marius> is already lcoked by one self is not very useful, since
> >     Marius> 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.
> 
> Yes.  But shouldn't a non-recursive mutex signal an error in this case?

No.  A non-recursive mutex should block in a case like this.

It's not an error to try and lock a mutex which is already locked,
even if it's already locked by your own thread.

Please, there are already standard semantics for these objects, in use
across a jillion languages.  Changing them is a little like deciding
that you are going to implement integer addition as NIM addition,
normal conventions be damned.

> Yes, true.  But what should be the default type?  We should offer
> recursive mutexes in any case, and I think they should be the default.

Why?  Recursive mutexes are much more heavyweight in general, and are
usually totally unnecessary.

> What about having only one type of mutex but different kind of locking
> functions?  One for recursive locks and one for non-recursive error
> checking ones.  That seems mighty clean to me.

The only implementation of such a thing which I've thought of ends up
imposing the extra cost of a recursive mutex on all users.