Boost logo

Threads-Devel :

From: David Abrahams (dave_at_[hidden])
Date: 2006-03-04 15:06:09


Matt Hurd <matt.hurd_at_[hidden]> writes:

> I'm no longer so sure the boost default is such a good idea especially as the
> performance of a recursive mutex on posix on a modern platform seems
> consistent with a non-recursive one in the main...
>
> I think having the recursive mutex as a consisent default across platforms
> will be a good thing and protect the average user, like me, from themselves.

The performance concern with recursive locks is not just about the
overhead of recursive locking: recursive locks are indication that the
granularity of the lock has been made to large (Butenhof “You are
also losing concurrency by keeping mutexes locked so long and across
so much context that you become tempted to use recursive mutexes to
deal with lock range conflicts.”)

Apparently Bill Kempf was considering making _all_ mutexes recursive
(http://lists.boost.org/Archives/boost/2000/08/4676.php). However,
it sounds like a mutex that asserts upon recursive locking might be
more valuable given the Butenhof quote above.

> Have a concept of a non-recursive mutex as a special case mutex
> raises an interesting point as on windows they don't exist, so the
> separate concept as a
> lowest_level_mutex_that_may_be_recursive_or_non_recursive_depending_on_your_platform
> which is the boost default remains useful.
>
> Any thoughts on this?

There's no point in a portable library in providing a mutex that
_might_ provide feature X. If you need feature X, just use the type
that's guaranteed to supply it. If the platform always provides
feature X, that doesn't necessarily mean the library has to always
expose it. Doing so will only encourage users to write nonportable
code, to no benefit.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Threads-Devel list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk