Re: [boost] [thread] RFC standard proposed mutex, read-write mutex, condition

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2007-08-25 16:36:56

Peter Dimov wrote:
> Yuval Ronen:
> 
>> Peter Dimov wrote:
>>> Yuval Ronen:
>>>
>>>> Checking in runtime is enough, IMO.
>>> How do you suggest this runtime checking be implemented?
>> assert(m_mutex.locked());
> 
> Well... this implies that a condition is always associated with a mutex

Of course a condition is always associated with a mutex. Except when it 
doesn't... So let's rewrite that line:

assert(m_mutex && m_mutex->locked());

> and 
> that the Mutex concept provides a locked() query, which it currently does 
> not.

Then we add such locked() query. And if we have to add a flag and 
increase sizeof(mutex), I have no problem with it, since it can be 
ifdefed for debug only. We only need the locked() query in debug.

> In principle one may check for a try_lock failure, although this doesn't 
> tell us which thread has locked the mutex.

At least in theory, a lock also doesn't tell us which thread has the mutex.

> Given that you already have a lock variable at the point you are calling 
> wait, what's wrong with just passing it? 

I may also have a std::vector<int> filled with prime numbers right 
there, but I don't pass it to wait(). A function should get what it 
needs, nothing more, nothing less. A lock is, IMO, redundant.

Oh, and BTW, I'm not sure I have a lock variable at that point. One 
possibility is that the wait() is performed not in the function that 
holds the lock, but form a deeper function (upper the call stack), which 
don't have access to the lock. Another "principal" argument is that I 
don't want to force using a lock. We added lock/unlock to mutex, and I 
think it's a good thing, because we think it's a needed flexibility. The 
user might even decide to use them... By adding smart pointer to C++, do 
we remove 'delete'? No. We encourage using smart pointer, but not 
forcing it.