Re: [boost] Re: Threads: the Mutex class

From: Branko Èibej (branko.cibej_at_[hidden])
Date: 2000-08-09 10:16:30

William Kempf wrote:
> Recursion is another very debatable topic.  It does
> add overhead, though in all honesty a recursive mutex can be modeled
> over a non-recursive mutex with very little effort and minimal impact
> to speed and size.

Having used both kind of mutexes in the past, I prefer _not_ to
allow recursive locking. The reason is simple: it fosters sloppy
design. It's easier to make it work, so there's less incentive
to make it right. I know some people will say that's a shaky argument,
but IMO designing for concurrency shouldn't be left to the unenligthened.

> Since recursive mutexes will prevent a lot of
> deadlock conditions I'm in favor of them, but let's hear the
> opponents to this speak up.

From my point of view they'll do exactly the opposite -- obscure
instead of prevent deadlock conditions. Finding the cause of a
deadlock in the presence of recursively-locked mutexes can be
the very devil.

There's also the question of deadlock detection: if recursive locking
isn't allowed, an attempt to do so can raise an exception. Granting
that this won't detect all possible deadlocks, at least the ones it
does will be caught earlier rather than later. always a good thing
IMHO.

Anyway, deadlocks can always be prevented by acquiring locks in the
correct order. What I would like to see in a threading library is
support for _enforcing_ correct locking order, for instance by
defining ordered lock groups.

-- 
Branko Èibej                 <branko.cibej_at_[hidden]>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
voice: ([phone]     fax: [phone]