On Sun, Apr 21, 2013 at 4:47 PM, Vicente J. Botet Escriba
Le 21/04/13 14:12, Dan Lincan a écrit :
Hello,
I would like to know if I'm going in the right direction.
Threadpool ideas: 1. simple * fixed number of threads ( possibly bound to number of cpus/cores ) * add_task
I don't like add_task. Maybe better use async, launch or submit. What would be the result?
The task/job would be added in the threadpool queue and, if there is a free thread, it would be runned.
2. simple + scheduling * variable number of threads - specify boundaries(min/max) - a lightweight algorithm in place to determine when to add / remove new threads withing boundaries to increase the throughoutput
What would be the advantage of having a dynamic number of threads?
Some of the submitted jobs might be blocking and it would take a lot of time for the jobs in queue to get completed. Increasing the number of threads would help in this case because it would speed up the completion of jobs. A limitation has to be in place though to avoid context switching overhead. Also, if there are a lot of idle threads for a long time, the number could be decreased to clear up resources.
What do you mean by scheduler?
The scheduler will determine when the algorithm to adjust the number of threads that are running. This could be every time a thread is looking for work if the algorithm is light ( O(1) ) .
* add_task * add_task_after(time_point) - the task will be scheduled only after time_point has passed - 2 possibilities ( relative time, absolute time )
It would be better to distinguish between launch after a duration and launch at a time point.
Then two functions should be provided: * add_task_after(abs_time) - fixed point in time * add_task_after(rel_time) - threadpool_start_time + rel_time
Why these time related functions are not on the simple thread pool?
It would introduce overhead which might not be O(1) depending on the algorithm used. Every time a thread would request work/job, checks would be in place to see if there is a job in the queue that can be executed at this point in time. This is the main reason I have separated them. 1. has zero overhead.
3. complex = simple + scheduling + work-stealing * variable number of threads * add_task * add_task_after(time_point) * work-stealing
All of them will use the chrono library for time mesurement.
For the proposal I have to point out where changes should be made in the current implementation at [1] or I need to provide a prototype of a new interface?
I would like to see a new interface on the proposal. [1] could be used to get insight on the domain. There is a on going c++1y proposal [2] that could help you. I would prefer however that the interface don't use dynamic polymorphism (inheritance) but a static one (concept). We can always adapt a dynamic polymorphic interface on top of the static one. The book CCiA [2] contains a lot of useful information related to the project. A mandatory book to read for the project. In particular there are implementation of static polymorphic thread-pools including work-stealing.
Great! I have started reading it. Regards, Dan
[1] https://svn.boost.org/svn/boost/sandbox/async/libs/tp/doc/html/index.html
[2] Executors and schedulers, revision 1 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3562.pdf [3] C++ Concurrency in Action by A. Williams.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost