[boost] Re: Boost.Threads inconsistency question

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-06-23 13:38:38

Doug Gregor wrote:
> On Wednesday 23 June 2004 10:51 am, Michael Glassford wrote:
> 
>>The Boost.Threads documentation states that the ScopedTimedLock concept
>>is a refinement of the ScopedTryLock concept; however, the
>>boost::timed_mutex::scoped_timed_lock class, which is supposed to be a
>>model of the ScopedTimedLock concept, doesn't define the various try_*
>>methods.
>>
>>In your opinion, should the documentation be changed to state that the
>>ScopedTimedLock concept is a refinement of the ScopedLock (rather than
>>ScopedTryLock) concept, or should the
>>boost::timed_mutex::scoped_timed_lock class implement the various try_*
>>methods?
> 
> 
> It sounds like the concepts are wrong. 

This is what I thought at first, too, but then I wasn't so sure: I 
forgot to mention that the TimedMutex concept *is* a refinement of the 
TryMutex concept, and the boost::timed_mutex class does provide typedefs 
for a scoped_lock, scoped_try_lock, and scoped_timed_lock. In other 
words, you can perform try_* operations on a timed_mutex, but you have 
to do it with a scoped_try_lock, not with a scoped_timed_lock. But in 
this case, why not just make scoped_timed_lock a superset of 
scoped_try_lock? Especially since, in some sense, a try_* operation is 
conceptually very similar to a timed_* operation with a time lapse of zero.

Not that I'm sure I'd really want to do that; I'm not sure what I think 
is best, yet, which is why I asked for opinions.

 > I'd suggest that the refinement clause in the docs be removed.

Or corrected: the ScopedTimedLock concept is a refinement of at least 
the Lock concept.

Mike