$include_dir="/home/hyper-archives/boost-users/include"; include("$include_dir/msg-header.inc") ?>
From: Anteru (newsgroups_at_[hidden])
Date: 2008-04-08 10:45:59
Hiho,
I'm using the new Boost Threads for a Thread Pool, however, I've got 
some weird problems.
The documentation of Condition::notify_one says it unblocks one of the 
threads waiting currently on the condition -- what happens if I have 
several threads waiting and I call notify_one twice?
It seems that on Windows/x64/VC9, only on thread wakes up if notify_one 
is called twice in a row. Is this right?
Second, wait says: "The thread will unblock when notified by a call to 
this->notify_one()  or this->notify_all(), or spuriously". Is it likely 
that a condition unblocks spuriously? After all, I'd expect to unblock 
only after calling notify_* and not "by accident". Is there any way to 
get diagnostic output when a wait has been called spuriously?
The problem I'm having at the moment is: I have PIMPLed Boost.Thread 
behind some simple wrappers, and I'm using them like this here:
Lock lock (mutex_);
if (queue.empty ())
{
        waitForItem.wait (lock);
}
with Lock being a wrapper for scoped_lock, mutex being a wrapper for 
mutex and waitForItem being a condition, and funnily enough it goes 
waiting even though there is an item in queue (i.e., queue.empty () == 
false). I'm not sure where this is coming from (all access to queue is 
protected using mutexes), only candidate at the moment is that when 
inserting, I call notify_one, and if two items get inserted one right 
after the other, I assume that only one thread is woken up and hence the 
other remains waiting although there is an item in the queue.
It works when I use notify_all (), but this does not smell right to me :/
Thanks,
   Anteru