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

Subject: Re: [Boost-users] thread_group::interrupt_all is not reliable
From: Stonewall Ballard (sb.list_at_[hidden])
Date: 2009-12-01 18:22:47

On Dec 1, 2009, at 6:05 PM, Roland Bock wrote:

> 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).

Ah, I'd missed that. Thanks for pointing it out. It takes several readings to understand all this.

>> 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.

May as well code a general-purpose pool so that it's debugged by the time you need it for another program.

Thanks again for your help.

- Stoney

-- 
Stonewall Ballard 
stoney_at_[hidden]           http://stoney.sb.org/