RE: [boost] Re: Lock unification

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

I like the suggestion of constructing an appropriate lock via the
appropriate constructor rather than a function (after all, that's what
constructors are for :-) ). Although I'd probably try being more
explicit 

typedef scoped_lock Lock;

Lock l(m);               // block
Lock l(m, Lock::try);            // try
Lock l(m, Lock::time(33));           // timed
Lock l(m, Lock::deferred);     // deferred

BTW, I love 'deferred'. IMHO it is very good and descriptive name for a
parameter. Much better than we had before (was it block/non-block?).

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of David Abrahams
> Sent: Friday, 16 July 2004 7:24 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: Lock unification
> 
> "Eric Niebler" <eric_at_[hidden]> writes:
> 
> > David Abrahams wrote:
> >> "Eric Niebler" <eric_at_[hidden]> writes:
> >>
> >>>I continue to believe that a better interface for a unified lock
> >>>involves descriptively named helper functions:
> >>>
> >>>scoped_lock l1( m );                 // lock unconditionally
> >>>scoped_lock l1 = defer_lock( m );    // don't lock
> >>>scoped_lock l2 = try_lock( m );      // try lock
> >>>scoped_lock l3 = timed_lock( m, t ); // timed lock
> >>>
> >>> It's just as clear as you could hope for,
> >> I'm not convinced it is.  It potentially puts information about the
> >> kind of locking being done very far from the actual call that does
> >> locking.
> >
> >
> > True, but the other design under consideration doesn't help with
> > that. It requires two-step construction for some constructs which
> > could result in code like:
> >
> >    scoped_lock l( m, false );
> >    maybe_takes_the_lock_i_dont_know( l );
> 
> I don't know what you're referring to.  I don't see any two-step
> construction going on there.  Links or examples, please?
> 
> >>>and it's extensible. I feel that the single lock c'tor with a bool
> >>>arg is less readable and rather inflexible.
> >> Inflexible how?
> >>
> >
> > User's can't add more constructors if they want a different locking
> > strategy, but they can add as many helper function as they like. For
> > instance, they could define a function that tried to take a
timed_lock
> > and logs failures. Or throws an exception. Or they could write a
> > lock_if helper that takes a predicate. And they can do all that with
> > simple one-step construction syntax. It's more concise and it
permits
> > the lock declaration to appear in the condition of if statements.
> 
> Sorry, I missed the "single lock ctor" part.  I think I agree with
> you there.
> 
> BTW, it just occurred to me that
> 
>      timed_lock(m, 0)
> 
> could potentially generate different code from
> 
>      timed_lock(m, some_int)
> 
> If we can detect literal zero... which I think is possible.
> 
> What about:
> 
>   scoped_lock l(m);               // block
>   scoped_lock l(m, 0);            // try
>   scoped_lock l(m, 33);           // timed
> 
>   scoped_lock l(m, deferred);     // deferred
>   scoped_lock l(deferred(m));     // alternate
> 
> ??
> 
> --
> Dave Abrahams
> Boost Consulting
> http://www.boost-consulting.com
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost