On 11/28/2010 02:09 PM, Howard Hinnant wrote:
With this "fair" behavior, imagine thread A getting shared ownership. Then thread B requests exclusive ownership and blocks until A relinquishes shared ownership. Meanwhile thread A recursively requests shared ownership. Thread A blocks because no more shared ownerships are granted
That's not what I think of as a 'recursive mutex' then. Seems to me a recursive mutex would not block A at this point. He wouldn't consider it 'granting a new shared ownership' but simply 'granting a redundant ownership for something the thread already owns'.
until thread B is granted exclusive ownership. Deadlock.
So don't design it that way then? Immediately grant any request for shared ownership if the requesting thread already has shared or exclusive ownership. Even if it doesn't match a literal interpretation of the fairness policy.
With recursive shared ownership on shared_mutex being a recipe for disaster, it might be confusing if the API offered recursive exclusive ownership on the shared_mutex.
Recursive mutex, to me, means "grant more of whatever the requesting thread already has, basically as a no-op." The calling thread isn't really acquiring anything new. Blocking him on something he already holds is a guaranteed deadlock. Whatever he's asking is for is probably going to help run his operation to completion, so it probably reduces contention on the exclusive lock too. Not saying this is a superior model in every way, just that it's what I grew up with. I think it's probably a little less prone to deadlocks, though perhaps a bit of code that deadlocked before could now corrupt data. But maybe that code would be broken in the single-threaded case too. - Marsh