Re: [Boost-users] [thread][repost] recursive shared mutex

Subject: Re: [Boost-users] [thread][repost] recursive shared mutex
From: Marsh Ray (marsh_at_[hidden])
Date: 2010-11-28 17:07:59

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