On Wednesday 23 June 2004 1:38 pm, Michael Glassford wrote:

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.

Could a timed_* operation with a time lapse of zero conceivably be much more expensive than a try_* operation on the same mutex? If so, then performance reasons could keep ScopedTimedLock from refining ScopedTryLock. Granted, the same performance reasons could then have kept TimedMutex from beiing a refinment of TryMutex. Reading the docs more closely this time, I don't see any other reasons against ScopedTimedLock refining ScopedTryLock. Doug