[threads] extension proposal
Hello, I would like to ask if it makes sence to introduce a data structure in boost::threads library, which implements a threads pool. Sometimes a system design can look like: Create a maximum of N threads and execute these threads with different tasks. If there more than N threads running then the threads_pool::get_thread(...) operation should block until one of threads gets ready. It is also possible to implement threads_pool::get_thread to use a policy which can block if the N is reached or return N+1 created thread. What I miss now in the threading library is the ability to reuse the thread. I think thread creation in the OS is an expensive task. If one has created thread, there should be a possiblity to reuse it. I understand it is possible to pass a function to the thread which executes tasks from the queue and therefore reuses threads, but this involves user implementation of such a function each time this programming pattern needs to be fullfilled. Would not it be a better idea to define a thread pool interface which has a synchronized queue (priority or not, should be customizeable) of tasks and pool of threads which are able to execute these tasks (boost::function0<void>) instances? I don't think I am the first person who comes up with this question... Would be really nice to hear your input on this issues or at least some links pointing to explanation, why this should not be done. With Kind Regards, Ovanes Markarian
Ovanes Markarian wrote:
If I remember correctly thread creation in Solaris at least is cheap and Sun's developer manuals explicitly recommend creating threads as needed rather than pooling them. I'm not sure about other OSes. It might be worth checking before designing such a pool. John.
Even if it is true, it should be possible to restict the creation to some certain number of threads (even without reuse) and wait until at least one of these will finish the execution, before new ones are created/started. What if I program a server which should accomplish tasks, but with a maximum ammount of 1024 threads. Then a function get_thread should block, until one of executing threads becomes ready or terminates. Or do you think such a system should create unlimited number of threads? I will read tonight a little bit more how the threads in Solaris, Windows and other Unix Systems work (especiall in regards of creation). On the other hand on Solaris and where threads are cheap to create a new thread should be created by the pool anyway... With Kind Regards, Ovanes Markarian On Mon, August 7, 2006 14:52, John Reid wrote:
On 8/7/06, Ovanes Markarian
Unless it has changed recently, thread Creation on Windows is expensive. However, instead of a thread-pooling system, I'd prefer a Task-queue system - create a task, add it to a queue, and the queue executes it on the next available thread - completely eliminate the concept of a thread. Tony With Kind Regards,
Tony thanks for your answer. May be you better described the point. When I wrote the idea, I was uncertain, how to name the structure, because it does not implement a real pool pattern. But the idea is to specify how many threads are allowed to be executed simultaneously and execute tasks on them. Tasks can be taken from a queue, "priority queue" or any other user specific queue. But these are implementation details. With Kind Regards, Ovanes Markarian On Mon, August 7, 2006 16:33, Gottlob Frege wrote:
Hi,
Would not it be more interesting then to write a
task-distributing class with the underlying mechanism
as a policy (thread pool, process pool, even
single-threaded)?
Best regards,
Vsevolod
--- Ovanes Markarian
http://lists.boost.org/mailman/listinfo.cgi/boost-users
http://lists.boost.org/mailman/listinfo.cgi/boost-users
http://lists.boost.org/mailman/listinfo.cgi/boost-users
http://lists.boost.org/mailman/listinfo.cgi/boost-users
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Win32 thread creation is relatively expensive, both in space and time. Windows 2000 and above provide QueueUserWorkItem and friends; the OS has a built-in thread pool.
participants (5)
-
Gottlob Frege -
John Reid -
Ovanes Markarian -
Stephen Hewitt -
Vsevolod Vlaskin