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

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-05 13:06:53

Batov, Vladimir wrote:
> According to the current Boost.Threads documentation timed_wait() does
> not require timed_lock (cut and pasted from
> http://www.boost.org/libs/thread/doc/condition.html#class-condition):
> 
> template <typename ScopedLock>
>     bool timed_wait(ScopedLock& lock, const xtime& XT);
> 
> Looking at the code it does appear to require timed_lock either:
> 
>     template <typename L>
>     bool timed_wait(L& lock, const xtime& xt)
>     {
>         if (!lock)
>             throw lock_error();
> 
>         return do_timed_wait(lock.m_mutex, xt);
>     }
> 
> What am I missing?

My mistake. I had simply forgotten that timed_wait didn't require a 
timed lock, and didn't check before I posted.

> BTW. How can I get to have look at the development branch? I went to
> http://cvs.sourceforge.net/viewcvs.py/boost/boost/development/ but found
> nothing threads-related.

At the bottom of the page is a menu labeled "Show files using tag:". 
Choose "thread_dev" in the menu. (You'll have to navigate to the 
boost/thread or libs/thread directory before this option appears in the 
menu, since that branch was only created for those two directories and 
their subdirectories.

BTW, ignore the thread_development branch, which is old.

> Thanks,
> V.
> 
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Michael Glassford
> Sent: Friday, 2 July 2004 4:35 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: Boost.Threads: Do we need all those mutexes?
> 
> 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
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>