Boost Users :
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
(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
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net