Boost logo

Boost Users :

Subject: [Boost-users] [boost][interprocess] upgradable_mutex is semi-recursive...
From: Lars Hagström (lars_at_[hidden])
Date: 2009-01-22 08:44:39


The subject is misleading, but hopefully eye-catching :-)
I do understand that this is not an interprocess bug, but more of a
result of how upgradeable locks work.
But the behavior can be dangerous, as will be seen.

What I've got happening is that one process locks the mutex recursively
(sharable, of course). And this works (most of the time), since it is
okay to lock the mutex shareably any number of times (even if it is
within the same thread).
But the problem occurs when a writer (in another thread) manages to get
inbetween these lockings, when we get this sequence

thread A locks mutex shareably
thread B waits for exclusive lock
thread A waits for sharable lock

Since the upgradable mutex is written so that if there is an exclusive
locker waiting it doesnt let any more sharable lockers in this will
deadlock.

Something that explains this could be useful in the interprocess
documentation.

Or, maybe the problem could be solved. I see two ways:

1. Detect recursive sharable locking, so that my thread A would always
get an exception when trying to lock a lock that I've already got (it is
a recipe for disaster)

2. Allow recursive sharable locks. If you've got the lock it's okay to
take it again.

Since I'm not really a fan of recursive locking (the above locking is a
mistake, really) I think I would prefer solution 1 of these two.

(I'm fixing my code to not be recursive now, but I thought this might be
of interest to either Ion or anyone using boost interprocess.)

Cheers
Lars


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net