Boost logo

Boost :

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) {}


1. underlying implementation would be much simpler and without
duplication as it'd always operate with basic_lock (good for
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

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 but found
nothing threads-related.


-----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
> I think widely accepted) OO design principle (guideline?) that in
> 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
> timed_lock and try_lock) or by keeping those three completely
> (probably at the expense of some code/functionality duplication). I am
> personally leaning towards latter, as even though technically all
> 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


   condition c;

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

         //do stuff

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


Unsubscribe & other changes:

Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at