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