Boost logo

Boost :

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


----- 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
>> _______________________________________________
>> Unsubscribe & other changes:
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at