Hi, I'm the author of a boost based thread pool lib (http://threadpool.sf.net) mentioned before in the "boost::thread queries" thread and I would like to give you some insight in the lib's future. As there's strong request for further features I plan to extend the pool step by step. Scott Meyers inspired me with policy based design at one of this C++ workshop and therefore I'm going to provide more policies for the pool. 1. Task scheduling policies Lifo, fifo, and priority based policies are already implemented. However, there's some work to be done to support bounded / blocking queues. 2. Pool resizing policies (Not implemented) These policies control the number of threads in the pool: Fixed pool, growing pool, bounded pool, dynamic shrinking, ... 3. Future creation policy (Not implemented) - General support for futures - Implementation independence: support for arbitrary future implementations (e.g. the future lib in boost vault) - I plan to provide a simple future implementation modelled on Peter Dimov's proposal http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2096.html 4. General design I think, the Java framework (J2SE5 as java.util.concurrent) is well designed. I plan to provide similar functionality (futures, dynamic pools, etc) without relying on the interface concept (using templates and boost::function/bind instead). I have not yet read the document "Multithreading API for C++0X" ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2094.html). Anyway, the threadpool lib should focus on providing a flexible, extensible, light-weight pool which can be used easily in high level concepts (like the Channel lib, fully featured futures, etc.). Any ideas and comments are welcome. Best regards, Philipp
Philipp Henkel wrote:
Hi,
I'm the author of a boost based thread pool lib (http://threadpool.sf.net) mentioned before in the "boost::thread queries" thread and I would like to give you some insight in the lib's future. As there's strong request for further features I plan to extend the pool step by step.
this sounds great! I use your lib in one of my current projects and it proved to be useful and stable. I have a question regarding changing the number of threads: sometimes I need to explicitly kill all worker threads. therefor I set the number of threads to zero using pool::resize(0) and wait for all active tasks to finish. this works as long as there are at least as many task in queue as there are threads to be killed. it does not work for empty queues. consider the following (pseudo) code: // create an empty pool with 5 worker threads pool p(5); // try to kill all worker threads (the queue is still empty) p.resize(0); since we did not add a task all worker threads are still running (waiting for some work to do). they will be killed as soon as we schedule some tasks. well, this isn't to bad at the first look. but in my special case each running worker thread acquires some kind of resource and I need to be able to create and remove worker on demand without any delay. I worked around the problem by scheduling a 'dummy-task' for each thread in case of an empty queue. but I am not convinced this is a good way of doing this ... do you think there is a better way? sascha
Hi Sascha,
I have a question regarding changing the number of threads:
sometimes I need to explicitly kill all worker threads. therefor I set the number of threads to zero using pool::resize(0) and wait for all
[...] since we did not add a task all worker threads are still running
(waiting for some work to do). they will be killed as soon as we schedule some tasks. well, this isn't to bad at the first look.
I regard this at least as a undesireable behaviour ;-) You may believe it or not: I stumbled about this problem some days ago while refactoring the code (it's not yet commited to CVS). A fast fix is to notify m_task_is_available right after m_thread_is_idle.notify_all(); in the resize method. Best regards, Philipp
participants (2)
-
Philipp Henkel -
Sascha Seewald