[boost] Threads Review

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-17 13:00:48

lock_concept.html - Why aren't we using the safe_bool idiom here?

faq.html 

 #1 - "Are lock objects thread safe"? Once again, using "thread safe"
      to describe objects and classes is a colloquiallism which I
      think is best avoided. How about "Can lock objects be shared
      between threads?".

 #5 - The second comment says "for the same reason we don't have to
      synchronize on construction. But the comment _is_ applied to a
      constructor definition. Why not just say "for the same reason"
      and stop there?

      operator=() contains undefined behavior unless both counter
      objects are part of the same array; you could use std::less to
      get around this. However, I think a comment which describes why
      you're ordering the mutexes in this way would be in order. I
      assume it's to prevent deadlocks in the case where thread A does
      x = y and thread B does y = x at the same time. I am also moved
      to suggest that you define operator< on mutex objects so that
      this idiom is harder to get wrong.

xtime.html

   Why are we defining an enum value TIME_UTC with ALL_CAPS? Is this
   thing really in the global namespace as the documentation implies?
   If there's a good reason for this, rationale should be
   provided. Also, the docs for this value seem to imply knowledge
   that I don't have. How is an enumeration value a "clock type?" is
   there some important reference missing here?

More to follow,
-- 
                    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