Re: [boost] [threads] Permission given to change to Boost.License
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. 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. "Task" is wider-popular term IMHO, but "task" in case of N2094 is just an optimization of "future". What about: "task" (instead of "future") and "movable_task", or "copyable_task" and "movable_task", or task<copyable> and task<movable> (pls see #1). 3. Functionality. Original boost::thread simplified multithreading programming because was: 1) portable 2) carefully designed Presented proposals go further on this way, because provide: 1) an ability to return results and to catch an exception (more about this later) 2) thread termination, if I've understood correctly But neither boost::thread nor proposals doesn't significantly simplify multithreading development. What about thread-safe message-queues and concurrency used in functional languages, e.g. erlang? Can you point me to any discussions about this topic? 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? :) It's possible all this questions were many times discussed in the past, so pls refer me. Best regards, Andriy Tylychko, telia@vichnavich.com
Andriy Tylychko (mail.ru) wrote:
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? :)
http://www.pdimov.com/cpp/future.cpp (referenced in N2096) has an example called pooled_executor that does this. N2090 threads and N2094 threads have no results; the result part is managed by N2096 futures (or N2094 tasks.) N2090 and N2096 are my proposals, and N2094 is an alternative proposal from Howard Hinnant.
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
participants (3)
-
Andriy Tylychko (mail.ru) -
Howard Hinnant -
Peter Dimov