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
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]
> 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
> > 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
> > 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
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk