[boost] More on Boost.Threads

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-16 16:00:20

* On condition.html

   a. What is the effective difference between notify_one() and
   notify_all()? In the absence of any information about the
   underlying system's scheduling mechanism, it seems as though there
   is none: either way, one blocked thread will get to execute with
   the mutex locked. If there is a difference between the two in
   practice, the documentation should give some indication of it.

   b. What is the rationale for condition::wait() throwing lock_error
   if !lock.locked()? Would it not be cleaner to simply lock the lock
   if it arrives in an unlocked condition?

   c. What is the rationale for the non-looping versions of wait() and
   timed_wait() which have no predicate? The docs say they're
   dangerous and should always be used with a loop, so why provide
   them?

   d. If the predicate form of wait(lock, pred) were implemented the
   way it's specified, there would be a race condition:

      while (!pred()) wait(lock);

   Since the predicate is checked before the non-predicate form checks
   for the lock being locked and throws an exception. Fortunately,
   your implementation doesn't work that way.

   However, I think I like:

      do { wait(lock) } while(!pred());

   better.

  e. misuse of the term `model'. Types model Concepts, objects do
  not. You should just be saying "mutex object", not "mutex model".

  f. The non-predicate form of timed_wait Effects: clause ends with
  "...and then reacquires the lock". This appears to mean the lock is
  reacquired regardless of whether timeout arrives before
  notification. I think that can't be intentional. Can it?

Another mail message will ensue for the next set of comments...

-- 
                    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