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?
> 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());
> that the Mutex concept provides a locked() query, which it currently does
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk