-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Friday, 16 July 2004 7:24 AM To: boost@lists.boost.org Subject: [boost] Re: Lock unification
"Eric Niebler" <eric@boost-consulting.com> writes:
David Abrahams wrote:
"Eric Niebler" <eric@boost-consulting.com> 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
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?). 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