Re: [Boost-users] [rerepost][threads] recursive shared_mutex

Subject: Re: [Boost-users] [rerepost][threads] recursive shared_mutex
From: Peter Dimov (pdimov_at_[hidden])
Date: 2009-05-05 11:32:53

joaquin tid dot es:
> I promise this is the last time I repost this; if I got no response I'll 
> go and try somewhere else :-/ thanks for your patience.
>
> As the docs do not explicitly say otherwise, I guess I must assume that 
> boost::shared_mutex is not recursive with respect to unique ownership, 
> that is, the following behavior ensues:
>
>   shared_mutex mutex;
>   lock_guard<shared_mutex> lock1(mutex);
>   lock_guard<shared_mutex> lock2(mutex); // DEADLOCK
>
> Is this so? In case boost::shared_mutex is indeed non-recursive, I've read 
> the following assertion on Hinnant's paper N2406 
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html ):
>
> "A recursive shared mutex could be built upon shared_mutex if desired, but 
> this is not proposed."
>
> Does anyone has a reference on how to construct a recursive shared_mutex 
> from a non-recursive one?

1. Recursive mutexes are evil.

2. The basic technique is

http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001082.html

(except that the store_release to count_ is not necessary, it's under a 
lock, count_ = 1 is sufficient)

but, as I point out, it requires an atomic thread ID type.

In the shared_mutex case, you'll want to use the same trick inside 
lock_shared to prevent the sequence exclusive_lock, shared_lock from 
deadlocking. shared_lock followed by exclusive_lock from the same thread is 
not worth supporting "properly"; luckily, it doesn't occur under the typical 
use patterns of recursive locking since const members don't call non-const 
ones.