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-05-04 13:58:58

Hi Vincente,

I'm sorry but I can't give you proper answers now because l don't have
internet access on my computer at my current location. I will get back home
in 2 days.

Regards,
Dan
On May 2, 2013 6:16 PM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]>
wrote:

> Le 02/05/13 11:58, Dan Lincan a écrit :
>
>> Hello,
>>
>> I have updated my proposal following your guide and tried to answer
>> and give solution to most of the problems. I have tried to separate
>> the interface with the implementation details so when choosing an
>> interface a feature can be easily added by following the exact
>> interface header so multiple implementations can be used without
>> affecting the user(ex: scheduling algorithm for dynamic thereads,
>> bounded/unbounded queues etc). I hope this approach is better.
>>
>> You can find the pdf version here [1]. The previous version of the
>> proposal can be found here [2].
>>
>> Thank you very much for the feedback, suggestions, guidance and the
>> really fast answers.
>>
>> [1] http://danlincan.3owl.com/**gsoc/final-proposal.pdf
>

>> [2] http://danlincan.3owl.com/**gsoc/Proposal.pdf
>
>>
>>  Hi Dan,
>
> *The new proposal contains:*
>
> *Waitable tasks*
>
> This feature gives the user the option to wait for a task to finish and
> retrieve its result.
>
> Drawback is that maybe the user is not interested in the result of the
> task.
>
> Interface
>
> template<classFunction,class..**.Args >
>
> boost::future<typenameboost::**result_of<Functionf()>::type>
>
> submit(Function&&f, Args&&args);
>
> My comments:
>
> what do you think of separating the responsabilities, the thread pool
> schedules Callables (void()) and a submit free function manage with futures:
>
> class thread_pool {
> public:
>
>  template<class Callable >
>  void submit(Callable&&);
>  ...
> };
>
> template<typename, Executor, class Function,class... Args >
> boost::future<typename boost::result_of<Function (Args...)>::type>
> submit(Executor& e, Function&& f, Args&& args);
>
> Implementing this function needs to use the same techniques than
> boost::async()*
>
> The new proposal contains:*
>
> *Task scheduling priority*
>
> The user would be allowed to give the tasks a priority, something similar
> to the operating system process priority: low, medium, high etc.
>
> Performance is lost when the algorithm to schedule tasks is running. Based
> on the implementation, this can be more that O(1), thus big overhead.
> Another problem is fair scheduling. Low priority tasks have to run at some
> point even if only high priority tasks are being submitted to the
> threadpool.
>
> Interface
>
> template<classFunction,class..**.Args ,class Priority>
>
> boost::future<typenameboost::**result_of<Functionf()>::type>
>
> submit(Function&&f, Args&&args, Priorityp = default_priority());
>
> My comments:
>
> I don't think adding priorities in this way would improve the performances.
>
> *The new proposal contains:*
>
> *Task execution order*
>
> For example the user might want x tasks to be executed, then only after
> all x have been executed another y can be executed and so on. So the user
> could assign the priority 1 to the x tasks and 2 to y tasks. The threadpool
> will know that level 2 tasks can only be executed after level 1 tasks are
> done.
>
> Performance is lost when a task is chosen to be executed. For example, if
> using priority queues, the complexity would be O(logn) plus the locks which
> can slow down a lot the scheduling.
>
> This feature can be used as a kind of serial executor by giving higher and
> higher numbers to the order argument.
>
> Interface
>
> template<class Function,class...Args ,class Order>
>
> boost::future<typenameboost::**result_of<Functionf()>::type>
>
> *submit**(**Function**&&***f*, **Args&&*args*, **Order*o= default_order());
>
> *Callback functions / Continuations*
>
> The user can also set a callback function when submitting a task to the
> threadpool. This function will run as soon as the task is finished by the
> threadpool.
>
> Drawback: Since the callback function is runned by the thread which
> executs the task, this thread can be block if the callback function is
> blocking. Also the callback has no parameters.
>
> Interface
>
> template<class Function,class...Args ,class Callback>
>
> boost::future<typenameboost::**result_of<Functionf()>::type>
>
> *submit**(**Function**&&***f*, **Args&&*args*, **Callback*c=
> default_callback());
>
> My comments:
>
> I prefer continuations than callbacks and prefer an interface that
> explicitly states the dependencies.
>
> when_all(submit(f), submit(g)).then(h);
>
> *The new proposal contains:*
>
> *Task cancellation*
>
> With this feature the use can cancel a submitted task. If the task is
> currently being executed it will be interrupted. For implementation
> boost::thread::intterupts will be activated.
>
> template<class Function,class...Args ,class Callback,class Task>
>
> boost::future<typenameboost::**result_of<Functionf()>::type>
>
> *submit**(**Function**&&***f*, **Args&&*args*, ****Task&*task);
>
> Task has the function cancel which cancels/interrupts when called.
>
> My comments:
>
> This is a little bit complex from the users point of view.
> I guess the best is to either:
> * adding to boost::future the possibility to interrupt the task, or
> * returning a interrupted_future<T> or task<T> that can be interrupted.
>
> There is an additional requirement. The user must ensure that all the
> tasks related to some object are executed sequentially but the task
> submission don't knows about the pending tasks.
> Continuations don't solve the problem. What would you add to make the
> users life easier?  (please read the discussion about threadpool and ASIO,
> the answer is someway there).
>
> Best,
> Vicente
>
>
> ______________________________**_________________
> Unsubscribe & other changes:
http://lists.boost.org/**
> mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
>