Hmmm . . . actually, as I&#39;ve been poking around, I think I&#39;ve I found some more explanations elsewhere which, if I&#39;m understanding them correctly, indicate that (a) I&#39;ve misunderstood what an upgrade_lock does, but also that (b) my code shouldn&#39;t be subject to<i> </i>the deadlocks you&#39;re describing (though it&#39;s clearly susceptible to others :-).<div>
<br></div><div>The key (which isn&#39;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&#39;s not the case: <a href="http://groups.google.mv/group/boost-list/msg/2c93110e9e3dbb45">http://groups.google.mv/group/boost-list/msg/2c93110e9e3dbb45</a>.)  This means that the behavior in my code could go something like:</div>
<div><br></div><div>- transmit() acquires shared_lock.</div><div>- createRoom() acquires upgrade_lock.</div><div>- deleteRoom() attempts to acquire upgrade_lock and blocks (because of the upgrade_lock held by createRoom()).</div>
<div>- createRoom() attempts to upgrade to a unique_lock and blocks (because of the shared_lock held by transmit()).</div><div>- transmit() releases shared_lock.</div><div>- createRoom() successfully upgrades to a unique_lock.  (deleteRoom() is still blocked because createRoom() already has an upgrade_lock)</div>
<div>- transmit() attempts to acquire shared_lock and blocks.</div><div>- createRoom() releases unique lock.</div><div>- deleteRoom() successfully acquires upgrade_lock.</div><div>- transmit() successfully acquires shared_lock.</div>
<div>- life goes on</div><div><br></div><div>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 <i>unique</i> locks.  But if I&#39;m understanding this correctly, I can&#39;t think of a scenario that would result in the behavior I&#39;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.)</div>
<div><br></div><div>That said, I&#39;m reasonably new to multithreading, and I&#39;m still having to think through these issues, so I might be missing something.  (Actually, I clearly am, I&#39;m just trying to figure out what it is :-).</div>
<div><br>Ken Smith<br>Cell: 425-443-2359<br>Email: <a href="mailto:smithkl42@gmail.com">smithkl42@gmail.com</a><br>Blog: <a href="http://blog.wouldbetheologian.com/">http://blog.wouldbetheologian.com/</a><br>
<br><br><div class="gmail_quote">On Fri, Apr 23, 2010 at 11:42 AM, Frank Mori Hess <span dir="ltr">&lt;<a href="mailto:frank.hess@nist.gov">frank.hess@nist.gov</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
On Friday 23 April 2010, Ken Smith wrote:<br>
</div><div class="im">&gt; On Fri, Apr 23, 2010 at 10:57 AM, Frank Mori Hess<br>
<br>
</div><div class="im">&gt; Yes, they are deadlocked because both upgrade locks are waiting for the<br>
&gt; other to release shared ownership so they can upgrade to unique ownership.<br>
&gt;<br>
&gt; Perhaps I wasn&#39;t clear.  They&#39;re not waiting on the upgrade_to_unique_lock<br>
&gt; lines, but on the upgrade_lock lines.<br>
<br>
</div>Despite my initial misunderstanding, your code still appears to be vulnerable<br>
to the deadlock I described, even if that isn&#39;t what you are hitting at the<br>
moment.<br>
<div class="im">-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.9 (GNU/Linux)<br>
<br>
</div>iEYEARECAAYFAkvR6i0ACgkQ5vihyNWuA4VNfQCfevtL72DQKITwIm8TaH3hk6z5<br>
TDAAnRyjfQVEitRqrlWtkzl/62EiG8Dc<br>
=+p2O<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br></div>