Boost logo

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
> ( ):
> "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, kalb at, bjorn.karlsson at, gregod at, wekempf at