This is just fair queue - if B has requested the lock before C, it should get it first. Or it can severely starve.<br>I was trapped with this behaviour once when one of my threads took shared_lock twice by error.<br><br>It looks like A should better wait for C&#39;s result NOT holding a shared_lock...<br>
<br><div class="gmail_quote">2010/9/22 George George <span dir="ltr">&lt;<a href="mailto:g_rambot@hotmail.com">g_rambot@hotmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">




<div>
threadA owns a shared_lock on the mutex, <br>threadB tries to get a unique lock on the mutex and blocks, <br>threadC tries to get a shared_lock on the mutex and blocks also!!<br><br>I guess there is a LIFO kind of stack serving the mutex to the requesting locks. But what happens if threadA depends on threadC in order to complete and release the lock?I n this case I have got a deadlock. Is this a design flow of my app or boost?<br>
 		 	   		  </div>
<br>_______________________________________________<br>
Boost-users mailing list<br>
<a href="mailto:Boost-users@lists.boost.org">Boost-users@lists.boost.org</a><br>
<a href="http://lists.boost.org/mailman/listinfo.cgi/boost-users" target="_blank">http://lists.boost.org/mailman/listinfo.cgi/boost-users</a><br></blockquote></div><br>