Re: [boost] [threadpool] version 22 with default pool

Subject: Re: [boost] [threadpool] version 22 with default pool
From: Edouard A. (edouard_at_[hidden])
Date: 2009-03-09 04:42:19

On Sun, 8 Mar 2009 23:35:00 +0100, "vicente.botet"
<vicente.botet_at_[hidden]> wrote:

>> Alternatively you can embed in your task some sort of synchronization
>> mechanism... But I think it's best to have the client write as little
>> synchronization code as possible.
> 
> Could you elaborate on this?

If you add a barrier in your task. The problem is to avoid having one
thread waiting for n threads. If you have threads waiting for each other, I
would say it's better.

If you are using a kernel object to wait, you pay the cost of a transition
even if you don't have to wait.

>> The problem is that you can have lots of tasks when sorting a container,
>> and
>> that means a lot of overhead with this approach. If I'm correct, if you
>> have
>> many tasks the wait_all starts to be slow. Maybe it's just a problem on
>> my
>> platform. I would need to investigate this further.
> 
> Why there is overhead? Why wait_for_all is slow?

I don't know. Maybe for the reason stated above.

-- 
EA