Re: Recursive mutexes?

[Marius Vollmer]

address@hidden (Thomas Bushnell, BSG) writes:

[ locking a non-recursive mutex when it is already locked by the same
  thread.]

> > 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.

Why?  Because it is cheaper, or because it is the Right Thing?

> 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.

What use does this have?  Are there well-known patterns were you rely
on this?

> Please, there are already standard semantics for these objects, in
> use across a jillion languages.

Are there?  Do they really all agree on whether mutexes are recursive
or not, and whether you are allowed to unlock a mutex from a
non-owning thread, and on what should happen when you lock a
non-recursive mutex that you already own?  I don't have that
impression, from my admittedly little experience.  Can you point me to
a description of these standard semantics?  You sound like they are
obvious, but they are not to me, yet.

> Changing them is a little like deciding that you are going to
> implement integer addition as NIM addition, normal conventions be
> damned.

It's more like deciding to offer bignums in addition, because they are
nicer than modulo 2^x arithmetic.  Most people don't want module 2^x
arithmetic when they use "int" in C, they just are careful to stay
within the region where C integer addition models real integer
addition.  What was the reason again to go to 64 bit?  That the UNIX
clock will not roll over? ;-)

Right now, I suspect that the reason d'etre for non-recursive mutexes
is that they are faster.  Nothing more.  I would like to hear other
reasons since the cost of recursive mutexes is not too high, in my
view.

> > 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.

"Much more" is a subjective measure.  As I see it, "much more" amounts
to two additional fields in the data structure and one comparison
during lock and unlock each.  This is not much more for the context
that our mutexes operate in.

> > 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.

Yes.  I am not trying to lower the cost here but to give non-recursive
mutexes to people who want them.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405