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

Subject: Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-21 18:20:10

Le 21/04/13 18:19, Dan Lincan a écrit :
> 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.
IMHO, this is an implementation detail. What the user wants is to launch 
a function asynchronously. Anyway naming is alway a source of conflict. 
This should be discussed specificaly on the Boost ML during the project.
>
>>> 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
Humm, I don't think it is a good idea the submitted jobs could block the 
worker thread. I think this could be the source of deadlock, but of 
course experimenting will always help us to learn more things. Maybe the 
proposal should include thread pools for blocking and non blocking tasks.
> 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.
I need to see some valid examples for which there is a need to block the 
worker thread. If you can include some on the proposal this will help to 
understand the motivation.
>> 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
submit_at, submit_after?
>> 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.
I see your point of view. All this depends how these operations are 
implemented. I need to think more about it.
>
>>> 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.
>
>
Do not forget to send your proposal today.

Best,
Vicente