Boost logo

Boost :

From: Eric Niebler (eric_at_[hidden])
Date: 2004-07-15 18:11:29

David Abrahams wrote:
>"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
>>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

Boost list run by bdawes at, gregod at, cpdaniel at, john at