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"
>> 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,
>> that means a lot of overhead with this approach. If I'm correct, if you
>> many tasks the wait_all starts to be slow. Maybe it's just a problem on
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk