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

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

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
>