[boost] More Threads Review

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-17 11:55:09

mutex_concept.html:

  "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