Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at