Boost logo

Boost :

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


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