|
Boost : |
From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-06-10 14:35:03
On Fri, 10 Jun 2005 22:14:41 +0300
"Peter Dimov" <pdimov_at_[hidden]> wrote:
> Jody Hagins wrote:
> > Notice one obvious issue: notify_one() and notify_all() still go
> > through
> > the native CV code to ping potential waiting threads. However,
> > without significant change to the current implementation of
> > condition, I do not see an easy way to prevent this.
>
> How is a condition variable supposed to behave when used with a null
> mutex? Is this a legitimate use case?
I believe it is a valid use case. Consider code for something like a
popping a message off a message queue. In such a case, the pop() member
function would block until the message queue was not empty. In a
single-thread case (i.e., using null_mutex), you would expect some kind
of exception, because you can not call pop with an empty queue in a
single threaded case.
while (this->is_empty_())
{
if (this->is_shutdown_())
{
throw shutdown_exception();
}
if (!this->is_get_active_());
{
throw get_inactive_exception();
}
auto_increment num_waiting(this->num_waiting_consumers_);
if (timeout)
{
if (!this->waiting_consumers_cv_.timed_wait(lock, *timeout))
{
throw timeout_exception();
}
}
else
{
this->waiting_consumers_cv_.wait(lock);
}
}
When lock is a normal mutex, the locking mechanism and the condition
variable work fine. If the lock is a null_mutex, all the code works
fine as well, but when it comes time to block, a thread_would_block()
exception is thrown from within the wait() or timed_wait() method of the
condition variable.
Thus, none of the code that uses locks and condition variables needs to
change, and ONE of several "right things" happens, namely an exception
is thrown, indicating that the thread would block. If you use a
null_mutex, you are not expecting to block on a condition variable,
because you better have all the data you need.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk