Boost logo

Threads-Devel :

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-04-14 09:52:09

Hash: SHA1

On Monday 14 April 2008 03:40 am, Anthony Williams wrote:
> Quoting Frank Mori Hess <fmhess_at_[hidden]>:
> > I'm curious if there is any theory on how to avoid deadlock when using a
> > shared mutex? Having a well-defined locking order works well for an
> > ordinary mutex, but things get messy with a shared mutex. For example,
> > if we have mutexes A and B then the locking sequence
> >
> > 1) shared lock A
> > 2) unique lock B
> > 3) upgrade to unique lock A
> My advice: don't do that. By sandwiching the lock to B within the two
> halves of the lock on A, you've exposed yourself to deadlocks on both
> sides, as you point out. This only happens if you start with an
> upgrade_lock on A, since otherwise you have to unlock the shared lock
> before you can take the unique lock, and taking an upgrade lock should
> be rare anyway, as there can be only one.

Oh, I had no idea that an upgrade lock had the highlander property. I thought
it was just a shared_lock with extra capability. The full significance of
the statement from the docs "a single thread may have upgradable ownership"
never sunk in.

I'm going to make acyclic_mutex treat any shared lock or upgrade just like a
unique locking event for the purposes of deadlock detection, with only two

- - for shared locks, a thread is allowed to take multiple shared locks on a
mutex and only the first lock_shared and last unlock_shared are recorded for
the locking order graph (similar to how recursive mutexes are handled).

- - upgrades are allowed if (and only if) the thread is upgrading the most
recently locked mutex that it is already holding.

- --
Version: GnuPG v1.4.6 (GNU/Linux)


Threads-Devel list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at