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

Subject: Re: [boost] [threadpool] version 22 with default pool
From: k-oli_at_[hidden]
Date: 2009-03-08 16:28:49

Am Sunday 08 March 2009 20:38:22 schrieb Edouard A.:
> I've also seen a lots of .lock() .unlock() in the code... Sometimes
> holding the lock is faster than releasing it and acquiring it again.

You have also to prevent deadlocks - so sometimes it would be faster to hold a 
lock but a deadlock could be raised. 

> I'm not sure it's a good idea to force the user to collect the tasks and
> wait for them. I thought threadpool could abstract that out. I mean, it's
> nice to have the alternative to wait for specific tasks, but generally you
> just throw in work into the pool and want that work to be finished...

that's what threadpool does - you submit work and you get for each item a 
handle (task) back. the pool schedules and executes the work inside to the 
worker-threads. the pool itself is not interessted in the result of the 
work-items nor should the pool have knowledge about the submitted work.
This can only be done outside the pool where you have anougth context.
So it makes no sense that the pool waits for a subset of the submitted work.

> Anyway, with wait_for_all, it's clearly slower than with shutdown().
Why? Waiting for the futures is only signaling that the result of the 
submitted work has calculated (done via condition variable inside the pool).

> Not really surprising as you go through more abstraction layers and you have 
> to store the tasks' results in a structure. IMHO, the fastest way would
> probably to have a condition_variable bound to the number of running tasks
> in the pool itself.
you could take a look into the future library - because future is used to 
transfer the result between threads (using condition variables inside).

Oliver