From: David Abrahams (dave_at_[hidden])
Date: 2002-10-17 11:55:09
"When exceptions are thrown, it becomes nearly impossible to ensure
that the mutex object is unlocked properly when using these
traditional API's. The result is deadlock."
Well, sort of. Isn't deadlock supposed to be when two threads are
waiting on one another to finish with some resource before proceeding?
Yes, that's how definitions.html specifies it.
I think what happens if you fail to unlock a mutex is that the
resource becomes permanently unavailable**, which is rather different,
though the behavior may appear to be similar.
**to other threads only, in the case of a recursive locking strategy
-- It may be late to change this, but I'd like the most-convenient names to correspond to the safer constructs. So, for example, I'd prefer it if "recursive_mutex" were called "mutex" and if the current "mutex" were called something else, though I can't think of a good name. Neither "nonrecursive_mutex" or "unspecified_locking_mutex" is very satisfying. -- In the Unchecked locking strategy, it specifies that re-locking the same mutex twice results in /deadlock/. Once again I think this doesn't correspond to our definition. Maybe what's meant is, "the thread blocks forever". I also wonder about the intention here. Is this really intended to be _specified_ behavior? Given the presence of an Unspecified strategy, it appears to be the case. I could imagine programs which took advantage of this behavior, which is why I'm asking. -- Speaking of "Unspecified", I think it's a bad idea to use this term for a locking strategy, especially since the behavior when re-locking an already-locked mutex is not "unspecified", but "undefined", which has a different meaning in the standard. I think this strategy should be called "non-recursive". -- In the description of "priority-driven" locking strategy, there's an out-of-the-blue mention of "one of the other scheduling priorities", with no reference to what this might be. I think that's just confusing. Maybe we should just say, "another strategy will determine..." -- Mutex concept: "Mutex object state can only be determined by an object meeting the ScopedLock requirements and constructed for the Mutex object." The meaning of the word "determined" is ambiguous here. It could mean "ascertained" or "affected". Now, I realize that in this case, both meanings apply, but I think we should clarify. Also, "constructed for" isn't very clear. Why not just say, "by an object constructed with the Mutex object as a parameter, whose type models ScopedLock" -- More remarks to come, -- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Building C/C++ Extensions for Python: Dec 9-11, Austin, TX http://www.enthought.com/training/building_extensions.html
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk