On Sep 18, 2006, at 6:36 AM, Andriy Tylychko (mail.ru) wrote:
From: Peter Dimov [mailto:pdimov@mmltd.net]
What does the Boost community think of
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2090.html http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2094.html http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2096.html
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.
Consider: 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 N2096:
The prototype implementation contains one additional Executor example that executes its tasks using a thread pool.
-Howard