Boost logo

Boost :

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.


>> [1]
> [2] Executors and schedulers, revision 1
> [3] C++ Concurrency in Action by A. Williams.
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at