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

From: Batov, Vladimir (Vladimir.Batov_at_[hidden])
Date: 2004-07-01 16:40:03

I am thinking maybe technically it would be much easier and cleaner to
implement one basic_lock (modeled on the current timed_lock) and then
provide specializations (you see, I am avoiding "refinement" :-) ) of it
to the user like:

try_lock : public basic_lock
{	...
        try_lock(mutex& m) : basic_lock(m, 0) {}
}

Then, 

1. underlying implementation would be much simpler and without
duplication as it'd always operate with basic_lock (good for
maintainers/implementers);
2. average users would still have friendly and simple interface;
3. advanced users might do much more tricky stuff by simply cutting to
the bone and using basic_lock.

Just a thought.

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Batov, Vladimir
Sent: Friday, 2 July 2004 7:25 AM
To: boost_at_[hidden]
Subject: [boost] Re: Boost.Threads: Do we need all those mutexes?

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?

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.

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