Re: [boost] Re: Boost.Threads: Do we need all those mutexes?

From: Doug Gregor (dgregor_at_[hidden])
Date: 2004-06-29 09:35:17

On Tuesday 29 June 2004 9:15 am, Michael Glassford wrote:
> Doug Gregor wrote:
> >>but the point is that all locks should have
> >>the same behavior in the 1-argument constructor case, and that is to
> >>block until this lock is obtained. The is the only way the user can use
> >>the lock in a generic way.
> >
> > Absolutely. This is *extremely* important to keep in mind when discussing
> > any kind of concept taxonomy.
>
> I would consider this more an argument for eliminating 1-argument
> constructors entirely (except for scoped_lock, where its meaning is
> completely unambiguous): there doesn't seem to be a
> way to define them that is both consistent within the lock class and
> consistent across lock classes (e.g. I agree with Vladimir that for
> consistency within the try_lock class, it should be non-blocking; but as
> Christopher pointed out, for consistency across lock classes, it should
> be blocking).

Right, so what we have (I think) are reasonably well-designed classes with 
incorrectly specified concepts. scoped_lock should really lock; try_lock 
should just try to lock.

> And, if you consider the larger case, which also includes
> read/write locks, single-argument constructors are even harder to define
> (do the read-lock or write-lock?; do they block or not?).

I'd expect scoped_*_read_lock and scoped_*_write_lock classes to be separate 
classes that model whatever locking concepts we come up with. Actually, the 
design of the read/write lock on the branch really surprised me, because it 
used the read_write_lock_state enum instead of distinct types.

> > Refinements of a concept can only add restrictions,
> > they cannot remove them.
>
> True. But it's not hard to define the concepts in such a way that the
> lock classes can have different constructors:
>
> Lock concept defines all lock operations except constructors.
> TryLock concept refines Lock by adding try_* methods.
> TimedLock concept refines TryLock by adding timed_* methods.
>
> ScopedLock refines Lock by adding appropriate constructors.
> ScopedTryLock refines TryLock by adding appropriate constructors.
> ScopedTimedLock refines TimedLock by adding appropriate constructors.

Looks perfectly reasonable to me.

        Doug