David Abrahams wrote:
"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?
With the single c'tor approach that Peter D. has been championing, to get a try lock, you need two statements: scoped_lock l( m, false ); if( l.try_lock() ) ... That's all I was refering to. Perhaps "2-step construction" is misleading. My point was, it's just as easy to make the locking logic remote with this design as with mine.
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
??
Interesting. That's workable. -- Eric Niebler Boost Consulting www.boost-consulting.com