|
|
Threads-Devel : |
From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-04-14 09:52:09
-----BEGIN PGP SIGNED MESSAGE-----
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
exceptions:
- - 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.
- --
Frank
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIA2GT5vihyNWuA4URAtKmAKDNWFuJ9uv4P9r5fx0E21WQ3PeP0QCghnOn
u79KX+ZY9q1dUpME4EtFkh4=
=hm88
-----END PGP SIGNATURE-----