On 28/11/2010 22:07, Marsh Ray wrote:

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.

Hi Are you familiar with this explanation why recursive mutexes are not actually helping to write better programs http://groups.google.com/group/comp.programming.threads/msg/d835f2f6ef8aed99... ? B.

On Nov 28, 2010, at 5:07 PM, Marsh Ray wrote:

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.

Fair enough. I guess to implement this the shared_mutex would need to keep a vector> of shared owners so that it can detect and track the recursion. -Howard

Howard Hinnant escribió:

On Oct 31, 2010, at 4:49 PM, JOAQUIN M. LOPEZ MUÑOZ wrote:

...

[Trying my luck again with this query.]

Hi,

Boost.Threads provides a recursive mutex and a shared mutex, but no recursive *and* shared mutex. Would it be a good idea to add this to the library? How hard is it to construct a recursive shared mutex from boost::sahred_mutex (i.e. adding reentrancy to boost::shared_mutex)?

Your question is somewhat vague: Are you referring to recursive exclusive ownership, recursive shared ownership, or both?

Sorry for the fuzziness: I'm referring to recursive exclusive ownership.

I suspect recursive exclusive ownership could be managed. However I believe a recursive shared ownership would be dangerous.

[explanation on the problems with recursive shared ownership]

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.

Why would this be confusing? Such a recursive shared mutex would be a model of recursive mutex providing additional non-recursive shared access. I don't see any risk of confusion here, since the patterns where exclusive and shared access occur are so different. Besides, the original request stems from a real need I've got of such a beast for one of my libraries. Even if the author of Boost.Threads does not consider it interesting to include this in the library, I'd be grateful if someone can provide an implementation that I can use it internally. Thank you, Joaquín M López Muñoz Telefónica, Investitgación y Desarrollo