Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk