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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-08 07:05:53

Michael Glassford wrote:
> Peter Dimov wrote:

[...]

>>>> This is certainly possible, but I don't see what the additional
>>>> complexity buys us.
>>>>
>>>>    TryLock l( m, false );
>>>>
>>>>    if( l.try_lock() )
>>>>    {
>>>>    }
>>>>
>>>> looks acceptable to me.
>>>>
>>>>    TryLock l( m, non_blocking );
>>>>
>>>>    if( l.locked() )
>>>>    {
>>>>    }
>>>>
>>>> doesn't seem much of an improvement.
>>>
>>> The two aren't equivalent (I'm not sure if you meant them to be): in
>>> your first example the constructor doesn't attempt to lock, and your
>>> second example it attempts a non-blocking lock.
>>
>>
>> I'm not sure where you think the two examples differ. Both attempt a
>> non-blocking lock.
>
> It doesn't really matter, but if you're talking about the way
> Boost.Threads works currently (in the 1.31.0 release), according to both
> the code and the documentation, TryLock(m, false) makes no attempt to
> lock. If you're talking about a new design, then of course it means
> whatever you want :)

I still don't see your point. Of course the constructor does not lock, but
the try_lock() call in the if statement does.

> That's one reason I prefer the enum: it's clear what the parameter
> actually means.

In this particular context, I don't think that the bool argument can be
misinterpreted, and neither can the explicit 'l.try_lock()' call.

>>> 2) What it buys over your suggestion (at the cost of complexity):
>>>
>>> * The ability to specify all applicable lock types (blocking,
>>> non-blocking, timed-blocking) in a constructor.
>>
>> Why is that an improvement?
>
> It seems reasonable that, if you're going to allow constructors to lock,
> you should allow them to lock in whatever ways are possible.

No, general principles say that it is usually unreasonable for a constructor
to leave the object in a Heisenberg state. ;-) As a general rule,
constructors establish invariants and therefore have postconditions (and
throw if they fail to meet those postconditions). Operations that are
expected to 'fail' are better expressed as (member) functions that return
whether the operation succeeded.

> The constructor locking is kind of nice for this syntax, though:
>
>     if (try_lock l(...)) //or timed_lock
>     {
>        //do something
>     }

It is. Unfortunately the syntax is illegal. ;-)