This is just fair queue - if B has requested the lock before C, it should get it first. Or it can severely starve. I was trapped with this behaviour once when one of my threads took shared_lock twice by error. It looks like A should better wait for C's result NOT holding a shared_lock... 2010/9/22 George George

threadA owns a shared_lock on the mutex, threadB tries to get a unique lock on the mutex and blocks, threadC tries to get a shared_lock on the mutex and blocks also!!

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?

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users