Subject: Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-12 02:07:43
Le 12/04/13 00:30, Vicente J. Botet Escriba a écrit :
> Le 10/04/13 17:02, Dan Lincan a écrit :
>> Hello,
>>
>> My name is Dan Lincan. I'm a 4th year undergratuate student in
>> Computer Science at the "Politehnica" University of Bucharest and I'm
>> interested in the project "Boost.Thread/ThreadPool".
>>
>> I have studied the documents provided as resouces and I would really
>> appreciate if you helped me better understand this project. Are there
>> any tasks that are meant to get solved for the proposal? How do I
>> start?
>>
>> I am aware that it will not be an easy task at all, especially because
>> I don't have much experience with boost, but I'm willing to learn and
>> work as much as it is needed to get it done.
>>
>>
> Hi,
>
> The project Boost.ThreadPool was developed taking in account the old
> Boost.Thread interface when the future library was not accepted in
> Boost yet. As far as I know the author (O. Kowalke) is working on an
> alternative design based on Boost.Context/Fibers instead of threads.
> IMO both approaches have a use depending on the application context.
>
> Two kinds of thread pools could be provided:
> * one simple and
> * another more sophisticated based on work stealing.
>
> The scheduled tasks could be non-blocking or blocking on the
> completion of other tasks.
>
> The goal of the project is to use the existing implementation as base
> and provide an interface that is compatible with the new Boost.Thread
> interface (based on the C++11 standard), and refactor it to avoid
> duplications (e.g. make use of a generic concurrent queue, ...)
>
> Once a Thread pool with these characteristics will be available we can
> start to adapt the boost::async and boost::future::then functions
> taking a scheduler as parameter.
>
> While this seems a big project, there is already a lot of work there
> and the provided services can be done proving first
> 1st simple thread pool scheduling non-blocking tasks
> 2nd add work stealing
> 3rd add blocking tasks
>
Ah I forget. One of the point to take in account in the interface is
move semantics (use of Boost.Move).
Vicente