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 18:12:01

Stonewall Ballard wrote:
[...]
>> 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?
> 
> Take a look at this:
> <http://www.justsoftwaresolutions.co.uk/threading/implementing-a-thread-safe-queue-using-condition-variables.html>
[...]
> I added the comment to the code in case someone came along later and decided that it was wasteful to notify_all().

Hmm. Have you read the section "UPDATE" on the page? To me that says 
that the requirement for the notify_all has already been taken care of 
in the presented code (by calling it each time a task is pushed).

>> 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).
> 
> This is the first time I've used boost::thread, so I guess that code is fairly new and not sufficiently beaten-upon. This discussion was very enlightening to me too. I greatly appreciate having experienced people available to look at the problem.
> 
> My code is running in the idle loop of a dialog window, so I had to avoid blocking the producer for more than a moment. Since there could be many more available tasks than threads, a queue was the obvious choice.

Yes, a blocking dialog would be bad. I am using the threadpool for a 
merge process which can delegate the processing of chunks to its 
workers. At the time I wrote it, I thought that blocking would not be 
problem (and in the intended scenario it isn't), because I can rarely 
use all available threads due to the sheer size of the chunks. The 
merger blocks that anyway.

But after today, I think I will change my pool. Limiting the number of 
tasks is part of the merge logic, the pool should not do something like 
that.

Regards,

Roland