Re: [boost] Re: Boost.Threads inconsistency question

From: Doug Gregor (dgregor_at_[hidden])
Date: 2004-06-23 15:20:26

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