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

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-06-29 10:55:20

Doug Gregor wrote:

> 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.

I'm not sure exactly what you're suggesting here. Are you talking about 
only the constructors, or would you completely eliminate all blocking 
functionality (e.g. the lock() method) from try_lock? And all non-timed 
functionality (e.g. the lock() and try_lock() methods) from timed_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.

There's a lot to be said for separate read-lock and write-lock types, 
and I was hoping to address that at some point; however, it would make 
lock promotion/demotion more difficult (unless maybe the read_lock class 
had a promote() method that returned a write_lock class or something 
like that, but that has some problems, too).

>>>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
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>