Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2006-09-24 17:54:32

On Sep 18, 2006, at 6:36 AM, Andriy Tylychko ( wrote:

>> From: Peter Dimov [mailto:pdimov_at_[hidden]]
>> What does the Boost community think of
> 1. Two different classes "future" and "task" with so simple goals
> and with a
> difference of just a single method's return type (almost). What do
> you think
> about some more lightweight approach? A new future's method
> (future::move_result() e.g.) instead of class "task"? Template
> parameter?
> Something else? Of course, if it's possible from implementation
> point of
> view.


Thread A
void foo(future<T> f)
     T t = f();

Thread B
void bar(future<T> f)
     T t = f.move_result(); // race condition?

By using a separate class task which is by design incapable of
sharing with future's, or even with other task's, it is clear that
there can be no race condition:

Thread A
void foo(future<T> f)
     T t = f();

Thread B
void bar(task<T> f)
     T t = f(); // ok

> 2. Naming.
> I think "future" and "task" names doesn't reflect the difference
> between
> them. More self-explanatory names can simplify learning.
> OTOH, I don't like the name "future". Of course, it's possible that
> I'm not
> very familiar with parallel computing terminology, don't beat pls,
> but it's
> completely new multithreading term for me that doesn't raise any
> contiguity
> with threads and parallelism.

"future" is a somewhat unfamiliar term to me in this context too.
However I'm hearing a lot of support for the term ("future" is a
*perfect* name, etc.). I.e. some people really like it a lot.

> "Task" is wider-popular term IMHO, but "task"
> in case of N2094 is just an optimization of "future".

More than an optimization. It allows move-only return types, which
imho will become very important in C++0X.
vector<unique_ptr<base_type>> alone probably justifies the existence
of move-only return types.

> What about: "task" (instead of "future") and "movable_task", or
> "copyable_task" and "movable_task", or task<copyable> and
> task<movable> (pls
> see #1).

While I'm not very attracted to any of these options, I am very
attracted to the idea of continuing to explore alternative names for
the future/task of N2094. Thanks for getting the conversation started.

> 4. Looping threads.
> Proposed design is best-suited for "single-task" threads. You have
> a task
> and you'd like to do it in a separate thread. This task has a
> result, and
> proposed design accents this. It's can be specific enough, but most
> of my
> threads work in loop, taking messages from the queue or just
> "working" until
> client explicitly stops them, and so doesn't have any results. So
> why I
> should worry about this, where's an interface for me? :)

Sounds very close to N2094's thread_pool or the class alluded to in

> The prototype implementation contains one additional Executor
> example that executes its tasks using a thread pool.


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