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