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.