If two threads hold an upgrade lock, and then both of them try to upgrade: -The first thread cannot upgrade to a unique lock until the second thread releases its upgrade lock. -The second thread cannot upgrade to a unique lock until the first thread releases its upgrade lock. Hence, deadlock. There are two ways to do read/write locks with upgradeability. The more common method used by most other libraries is to make the upgrade a non-blocking tryUpgrade() method or similar. The approach used by boost::threads is, IMO, smarter, but more confusing at first. Here is the key: An upgrade lock is *not* a special type of read lock that can be upgraded. Don't think of it that way. Instead, think of it as a special type of write lock that can allow simultaneous read locks. To use boost::thread terminology, multiple upgrade_locks cannot be simultaneously taken on the same mutex; however, while a single upgrade_lock is taken, an arbitrary number of shared_locks can also still be taken on the same mutex. So: unique_lock: No other locks may be taken at the same time. upgrade_lock: Other shared_locks may be taken at the same time, but no other upgrade locks. shared_lock: Other shared_locks may be taken at the same time. You need to keep this in mind when coding, and keep your upgrade_lock usage restricted to those places where you *really* need it. On Thu, Mar 27, 2014 at 12:09 PM, Elad Moshe wrote:

...

If both threads tried to upgrade, you would have a deadlock.

But how is it possible? isn't the upgrade operation atomic? if the 2 threads try to upgrade, one will succeed and the other one will block until the first thread will unlock.

On Thu, Mar 27, 2014 at 5:39 PM, Steven Watanabe wrote:

...

AMDG

On 03/27/2014 01:21 AM, Elad Moshe wrote:

...

Hi, this is my first post here so please bare with me :) . I recently used upgrade_lock to try access a shared resource from 2 different threads. I noticed that once the first thread acquired its upgrade_lock the second thread was blacked until the first thread unlock it. can someone please explain me the logic behind this behavior? isn't an upgrade lock just a shared_lock that can be upgraded to unique_lock? why not let both threads acquire it just like shared_lock until, and if, they decide to upgrade it to unique_lock?

If both threads tried to upgrade, you would have a deadlock.

In Christ, Steven Watanabe

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

AMDG On 03/27/2014 09:09 AM, Elad Moshe wrote:

...

If both threads tried to upgrade, you would have a deadlock.

But how is it possible? isn't the upgrade operation atomic? if the 2 threads try to upgrade, one will succeed and the other one will block until the first thread will unlock.

If it worked this way, it would mean that upgrade lock would not exclude concurrent writes, which completely defeats the point of using it in the first place. In Christ, Steven Watanabe