[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)? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
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? I suspect recursive exclusive ownership could be managed. However I believe a recursive shared ownership would be dangerous. I think it would have to choose between two designs, one which risked deadlock, or the other which risked exclusive ownership starvation. Rationale: The current shared/exclusive priority design (which is by Alexander Terekhov and I think is a good one) will cease to grant shared ownership after exclusive ownership has been requested. This allows time for the shared owners to dwindle down to zero so that the exclusive ownership can be granted. Without this behavior, and with many shared owners, even if no one shared owner owned the lock for very long, an exclusive owner would always be waiting. Imagine if everyone kept cutting in front of you while you waited in line. 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 until thread B is granted exclusive ownership. Deadlock. 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. -Howard
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
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 11/28/2010 04:18 PM, Bronek Kozicki wrote:
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...
No, I had not seen that. It's an interesting post, thanks for linking it. The author may be correct in everything he writes, but it's certainly not the only point-of-view. One could find examples to support any point-of-view, which is not to say that I think all points-of-view are equally valid. What is clear, however, is that this subject has a big potential for ideological disagreements. Which is why I tried to be very limited in what I wrote. For example, I specifically did not claim that "recursive mutexes help you write better programs". Instead, I was careful to write:
Not saying this is a superior model in every way, just that it's what I grew up with.
:-) -Marsh
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<pair<thread::id, unsigned>> of shared owners so that it can detect and track the recursion. -Howard
On 11/28/2010 04:22 PM, Howard Hinnant wrote:
I guess to implement this the shared_mutex would need to keep a vector<pair<thread::id, unsigned>> of shared owners so that it can detect and track the recursion.
Or perhaps a few bytes of thread-local storage? Don't know if that's fair game for this implementation. - Marsh
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
participants (5)
-
Bronek Kozicki -
Howard Hinnant -
JOAQUIN M. LOPEZ MUÑOZ -
joaquin＠tid.es
-
Marsh Ray