On Aug 25, 2007, at 2:52 PM, Yuval Ronen wrote:
I find the lock argument cumbersome. In a way it's redundant to passing the mutex, and for no good reason - just for hinting, subtle or no subtle. Where else in C++ a user is hinted in such a way? It's without precedent, and plain weird in my eyes. And if we add to this the fact that it's only a partial compile-time check, then it makes things even weirder. The user, for example, can confuse and think that he is fully covered by the compile-time check, and continue with his guards down, passing it a non-owning unique_lock. If we can't do a complete job, it's better to not do it at all, at least this way our users are forced to be aware of what's happening.
We have to have a wait which takes at the very least a mutex, if not a lock. This is to support the legal "dynamic" binding mutex binding. We could possibly achieve the same functionality through your set_mutex suggestion, but that interface seems error prone to me, as it then takes two calls to wait instead of one: condition<mutex> cv; ... while (true) { Data d = get_data(); unique_lock<mutex> lk = d.get_lock(); d.process(); while (d.not_ready_to_pass_on()) { cv.set_mutex(lk.mutex()); cv.wait(); } stream << d; } as opposed to just: while (d.not_ready_to_pass_on()) cv.wait(lk); One possibility would be to have both wait(lock) and set_mutex(mutex)/ wait(). But this doesn't allow anything that wait(lock) alone allows. -Howard