Re: [Boost-users] thread_group::interrupt_all is not reliable

Subject: Re: [Boost-users] thread_group::interrupt_all is not reliable
From: Roland Bock (rbock_at_[hidden])
Date: 2009-12-01 16:07:13

Stonewall Ballard wrote:
> The test code is parked at <http://sb.org/ThreadTest.zip>, 20KB. It's
> an XCode 3.2 project, but the five source files could be readily
> compiled and run in any Unix environment.

I admit it took several times of reading this thread until I finally 
thought I got it (which might have something to do with several rather 
long days of PHP & JavaScript hacking).

Apart from the original problem, I wonder if you could shed some light 
on a comment in your WorkQueue code:

CONTROL:
     void increment()
     {
         boost::mutex::scoped_lock lock(the_mutex);
         ++tasks_available;
         lock.unlock();
                 // notify_one may fail to wake a worker if there
                 // are multiple items in the queue, so it's better
                 // to waste a bit of CPU and notify_all
         the_condition_variable.notify_all();
     }

WORKER:
     void wait_and_decrement()
     {
         boost::mutex::scoped_lock lock(the_mutex);
         while ( tasks_available == 0 ) {
             the_condition_variable.wait(lock);
         }
         --tasks_available;
     }

What would be a scenario in which notify_one would fail? I would assume 
that a problem with notify_one would occur only if you would do 
something like

tasks_available += 42;

instead of

++tasks_available;

In such a case, notify_one would wake less threads than required. But 
how can that happen with notify_one being called for each and every task?

Regards,

Roland

PS: Thank you for starting this thread (and Peter and Anthony for 
participating, of course). Very interesting, because I have written a 
different kind of threadpool a few days ago (no queues, but you can call 
a method addTask() which will hand the task to the next thread available 
(blocking for as long as all threads are working on previously added 
tasks)). The destructor calls interupt_all() with potentially many 
threads in wait(). I probably would have run into the same problems as 
you did when using it in production (8-core).