Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project

Subject: Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
From: Dan Lincan (dan.lincan_at_[hidden])
Date: 2013-04-21 12:19:37

On Sun, Apr 21, 2013 at 4:47 PM, Vicente J. Botet Escriba
<vicente.botet_at_[hidden]> wrote:
> 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