On Sun, 8 Mar 2009 23:35:00 +0100, "vicente.botet" <vicente.botet@wanadoo.fr> 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