Re: [boost] [thread-pool/futures] Explicit yielding

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-06-09 12:55:22

Please, forget my last message. It was sent unintentionally ...

_____________________
Vicente Juan Botet Escriba
----- Original Message ----- 
From: "vicente.botet" <vicente.botet_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, June 09, 2008 6:49 PM
Subject: Re: [boost] [thread-pool/futures] Explicit yielding

>
> Hello,
>
>
> ----- Original Message ----- 
> From: "Kowalke Oliver (QD IT PA AS)" <Oliver.Kowalke_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Monday, June 09, 2008 1:53 PM
> Subject: Re: [boost] [thread-pool/futures] Explicit yielding
>
>
>> For what would be 'task-stealing' be usefull?
>> Wouldn't be one task-queue on which worker threads are waiting be
>> sufficient?
>
> It may be sufficient, but it can be ineficient.
>
>> Polling of one thread in task-queues of other threads seams to be
>> expensive.
>
> You are right, the main raison this is expensive is that we need to
> synchronize the access to this shared resource. But this is already the 
> case
> when we have only one task-queue.
>
> I think that the quiz is that we need to manage the root-task(without
> parent) and the sub-task(with a parent task) differently. root-task must 
> be
> handle in fifo order, but sub-tsaks are needed to complete other tasks, so
> they need to be handled in lifo order.
>
>
> What happens if we have only one queue? We need to synchronize the access 
> to
> the single queue for every task, and as you say this is expensive. So we
> need to avoid to synchronize with other threads as much as possible.
>
> What happens if a task needs to wait on futures provided by other 
> subtasks?
> We can make the worker thread wait directly on this future blocking one
> thread, or we can try to execute other tasks.
>
>
> As very often a task is waiting for futures provided by task launched by 
> the
> task itself, it will be better that these subtasks run on the same worker
> thread (this avoid thread switching). In order to do that we need a stack 
> of
> subtasks. But even in this case the worker thread would have is stack of
> task empty, and here he can just take a task from the queue of other 
> threads
>
>
>
>>> Johan Torp:
>>> > Does existing threadpools (such as
>>> > java.util.concurrency.ExecutorService)
>>> > offer thread re-use and if so is it considered an success?
>>>
>>> Doug Lea says that ThreadPoolExecutor doesn't steal threads,
>>> but the upcoming ForkJoin framework does. ForkJoin is described in
>>>
>>> http://gee.cs.oswego.edu/dl/papers/fj.pdf
>>>
>>> _______________________________________________
>>> Unsubscribe & other changes:
>>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>