Re: [Boost-users] Troubleshooing deadlock with upgrade_lock<shared_mutex>

Subject: Re: [Boost-users] Troubleshooing deadlock with upgrade_lock<shared_mutex>
From: Ken Smith (smithkl42_at_[hidden])
Date: 2010-04-23 15:10:09

Hmmm . . . actually, as I've been poking around, I think I've I found some
more explanations elsewhere which, if I'm understanding them correctly,
indicate that (a) I've misunderstood what an upgrade_lock does, but also
that (b) my code shouldn't be subject to* *the deadlocks you're describing
(though it's clearly susceptible to others :-).

The key (which isn't clearly noted in the documentation) is that an
upgrade_lock is like a unique_lock in that only one upgrade_lock can be held
at a time.  (I was thinking it was more like a shared_lock, in that multiple
instances of it could be held at the same time, but Anthony Williams
indicates that's not the case:
http://groups.google.mv/group/boost-list/msg/2c93110e9e3dbb45.)  This means
that the behavior in my code could go something like:

- transmit() acquires shared_lock.
- createRoom() acquires upgrade_lock.
- deleteRoom() attempts to acquire upgrade_lock and blocks (because of the
upgrade_lock held by createRoom()).
- createRoom() attempts to upgrade to a unique_lock and blocks (because of
the shared_lock held by transmit()).
- transmit() releases shared_lock.
- createRoom() successfully upgrades to a unique_lock.  (deleteRoom() is
still blocked because createRoom() already has an upgrade_lock)
- transmit() attempts to acquire shared_lock and blocks.
- createRoom() releases unique lock.
- deleteRoom() successfully acquires upgrade_lock.
- transmit() successfully acquires shared_lock.
- life goes on

Now, if transmit() were regularly taking longer than 20 ms to complete, so
that it was regularly being called reentrantly, I could imagine that it
would build up a pretty good backlog of shared locks, which would prevent
createRoom() and deleteRoom() from acquiring their *unique* locks.  But if
I'm understanding this correctly, I can't think of a scenario that would
result in the behavior I'm seeing, i.e., both the createRoom() and
deleteRoom() methods blocking each other while attempting to acquire an
upgrade_lock.  (Since no other unique or upgrade locks appear to be held
elsewhere at the time.)

That said, I'm reasonably new to multithreading, and I'm still having to
think through these issues, so I might be missing something.  (Actually, I
clearly am, I'm just trying to figure out what it is :-).

Ken Smith
Cell: 425-443-2359
Email: smithkl42_at_[hidden]
Blog: http://blog.wouldbetheologian.com/

On Fri, Apr 23, 2010 at 11:42 AM, Frank Mori Hess <frank.hess_at_[hidden]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Friday 23 April 2010, Ken Smith wrote:
> > On Fri, Apr 23, 2010 at 10:57 AM, Frank Mori Hess
>
> > Yes, they are deadlocked because both upgrade locks are waiting for the
> > other to release shared ownership so they can upgrade to unique
> ownership.
> >
> > Perhaps I wasn't clear.  They're not waiting on the
> upgrade_to_unique_lock
> > lines, but on the upgrade_lock lines.
>
> Despite my initial misunderstanding, your code still appears to be
> vulnerable
> to the deadlock I described, even if that isn't what you are hitting at the
> moment.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkvR6i0ACgkQ5vihyNWuA4VNfQCfevtL72DQKITwIm8TaH3hk6z5
> TDAAnRyjfQVEitRqrlWtkzl/62EiG8Dc
> =+p2O
> -----END PGP SIGNATURE-----
>