Peter Dimov wrote:
Yuval Ronen wrote:
Peter Dimov wrote:
Howard Hinnant wrote:
Or should condition::wait() not take any parameters, or take only mutexes, making the issue moot? I think that we ought to keep the lock argument, even if we end up not using it for anything except debug checks. It helps people avoid accidental calls to 'wait' without locking the mutex first. If, by "It helps people avoid accidental...", you mean "at compile time", then it's not always detected in compile time, because the existence of a lock doesn't mean a mutex is locked (e.g. unique_lock).
I meant "helps people avoid accidental mistakes at the time they're writing the code". The function encourages correct use by asking for a lock, implying that the mutex needs to be locked first.
Hinting the user to lock a mutex by accepting a lock is getting too psychological for my taste. If it was enforced by the compiler, then maybe, but since the compiler can't... When it comes to locking, nobody hints anyone to lock a mutex before accessing a shared resource - it's the user responsibility, and we assume he does it. No hinting or hand-holding is required. The last sentence is both a "psychological" argument, and a technical one. The technical being that if before the call to wait(), the user accesses a shared resource (the while condition), and if the user pedantically locks when it comes to shared resources, then the mutex is locked when calling wait(), and there's no need to hint. That said, I know that any "psychological" debate has the potential of never being settled. Too many things depending on "taste". It's even less of an exact science than computer science :)
There was an article by Andrei Alexandrescu somewhere on informit.com where he advocated a similar pattern: the functions that assume that a mutex has been locked should take a lock argument.
Did he take unique_locks into account?