From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-06-29 09:15:19
Doug Gregor wrote:
> On Tuesday 29 June 2004 8:00 am, Christopher Currie wrote:
>
>>>The basic usages (covering about 80%) are:
>>>
>>>scoped_lock l(m); // Block until it locks.
>>>scoped_try_lock l(m); // Try (!) to lock. I'll check the result.
>>
>>I disagree here, as well. Say I want to program generically...
>>
>>template <typename Mutex, typename Lock>
>>class worker_class
>>{
>> Mutex m_;
>>
>>public:
>> do_work()
>> {
>> Lock l(m_); // Does this call block?
>> // am I guarenteed to be locked here?
>> }
>>}
>>
>>Yes, it's a contrived case,
>
>
> I don't believe it is a contrived case. Certainly once we have read/write
> mutexes we're going to want to tell generic components which kind of lock
> they need to use.
I was going to ask if locks were likely to be used generically in this
way; obviously they will, in your opinion.
I appreciate your bringing up read/write locks; I was planning to bring
them into the discussion as well.
>>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). 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?).
> 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.
Mike