Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk