On Fri, 10 Jun 2005 22:14:41 +0300 "Peter Dimov" <pdimov@mmltd.net> 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.