Boost logo

Boost :

From: Christopher Currie (codemonkey_at_[hidden])
Date: 2004-07-15 15:04:12


Michael Glassford wrote:

> Actually, if you've been following the whole discussion, you'll know
> that I agree with you.

My appologies, I lost track of the thread a while back, and haven't had
the time to catch up.

> try lock, or a timed lock, and to remove the ambiguity in the try_lock
> constructors (rather arbitrarily, one is blocking, the other
> non-blocking, even though they look just like the lock class
> constructors which both block).

I'm on the fence on this issue; since it's been put off until after the
next release I won't go into it here.

> Actually, it has been true all along that (except for constructors) a
> try lock is a superset of a plain lock, and a timed lock was nearly a
> superset of a try lock. I wanted to (and have in the upcoming release)
> made timed lock an actual superset of a try lock by adding a try_lock()
> member function to it.

I would actually prefer that timed_lock *not* be a superset of try_lock.
The documented concepts clearly don't imply that, it appears to be an
artifact of the implementation. If you happen to want to use try_lock
semantics on a timed_lock, it's easy enough to use a zero timeout.

>
>> template <typename mutex_type>
>> foo( mutex_type & m )
>> {
>> mutex_type::scoped_lock l( m );
>>
>> // do work
>>
>> l.unlock();
>>
>> // do more
>>
>> l.try_lock(); // compile time error?
>>
>> // still more
>> }
>>
>>
>> If the locks are combined, whether this is an error is dependent on if
>> the mutex supports a try_lock operation, whereas with the existing
>> interface, this is always an error, because I've said up front that I
>> only ever want to perform blocking locks here.
>>
>> I'll also point out that the existing interface supports the opposite
>> desire, a compile time error based on mutex_type:
>>
>> template <typename mutex_type>
>> foo( mutex_type & m )
>> {
>> // compile time error possible
>> mutex_type::scoped_try_lock l( m );
>>
>> // do work
>>
>> l.unlock();
>>
>> // do more
>>
>> l.try_lock(); // ok
>>
>> // still more
>> }
>>
>>
>> This will compile if a TryMutex is passed, but not a plain Mutex,
>> because scoped_try_lock is not defined for that type.
>
>
> Of course this would be true with the single-lock scheme also.

True, it's the first case that doesn't appear to be possible with the
single-lock scheme. In otherwords, I want the *lock* to prohibit the
try_lock operation, not the mutex.

>> In the end, I feel that by combining the interfaces, we take away the
>> ability of the user to be explicit and restrictive in her use of lock
>> types.
>
> So would you advocate removing the lock() method and the blocking lock
> constructors from try_lock and timed_lock? I think the three most
> consistent designs would be:
>
> 1) No overlap between lock, try_lock, and timed_lock.

As it stands, I feel I would advocate this option, at least among
constructors, perhaps leaving the lock() method intact. Though I
wouldn't cry if it were taken away, because it isn't strictly necessary,
just a convenience.

> Then you'll be glad to know that most of my Boost time is being devoted
> to adding new features (mostly features at least partially implemented
> by the original Boost.Threads author before he stopped working on it).
> See http://tinyurl.com/4wdtz (note that it will be slightly out of date
> until the page is refreshed).

Thanks to you, for picking up the reigns to maintain it. I know you've
done a lot of work to ensure that Boost.Threads has not grown stagnant,
and matures.

Christopher

-- 
Christopher Currie <codemonkey_at_[hidden]>

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