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]>
Sent: Monday, June 09, 2008 6:49 PM
Subject: Re: [boost] [thread-pool/futures] Explicit yielding
> ----- 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
> It may be sufficient, but it can be ineficient.
>> Polling of one thread in task-queues of other threads seams to be
> 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
> 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
> 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
> 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
> 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
> 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
> 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
>>> 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
>>> Unsubscribe & other changes:
>> Unsubscribe & other changes:
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk