[boost] Re: Boost.Threads: Do we need all those mutexes?

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-01 13:34:55

Batov, Vladimir wrote:

>>Well, as you point out, try_lock is like a timed_lock with
>>time = 0, and lock is like a timed_lock with time = infinity,
>>so why not give timed_lock both lock() and try_lock()
>>methods as shorthand notation for lock(m, t=0) and
>>lock(m, t=infinity)?
> 
> 
> [Batov, Vladimir] Because, in my view, it violates the fundamental (and
> I think widely accepted) OO design principle (guideline?) that in simple
> terms can be expressed as "one class, one responsibility". Names like
> Bertrand Meyer, Herb Sutter and many others immediately come to mind.
> 
> We can either achieve that by having a universal lock (with timed_lock
> as the basis) and shorthand notations in separate derived classes (lock,
> timed_lock and try_lock) or by keeping those three completely unrelated
> (probably at the expense of some code/functionality duplication). I am
> personally leaning towards latter, as even though technically all three
> concepts are related, from the user point of view they are distinct.
> 
> 
>>The argument for try_lock not having a blocking lock() method,
>>which you seem to stress more often, is much clearer; I'm much
>>more inclined to agree with you there.
> 
> 
> [Batov, Vladimir] Thank you. I feel that it is important that every
> class does what it promises to do. No more, no less.

For what it's worth, heres a use case I just ran across illustrating why 
timed_lock should have a blocking lock() method and/or a blocking locked 
constructor:

   condition c;

   void f(mutex m)
   {
     mutex::scoped_timed_lock l(m, locked);
       //always want the lock here

     for(;;)
     {
         //do stuff

         c.timed_wait(l, next_wakeup_time());
           //timed_wait requires a timed_lock
     }
   }

Mike