|
Boost : |
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2007-08-25 16:10:02
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk