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

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-08 09:34:29

Peter Dimov wrote:
> 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.

Brain damage on my part, I guess. I've been reading and replying to many
too many of these messages.

All I meant is that the constructors themselves aren't the same, but you
already knew that.

>>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. ;-)

Yes, as I commented elsewhere it was too late at night and I missed
that. See another message where I suggest a syntax that should work.

Mike