Re: [boost] [threads] Permission given to change to Boost.License

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

On Sep 18, 2006, at 6:36 AM, Andriy Tylychko (mail.ru) wrote:

>> From: Peter Dimov [mailto:pdimov_at_[hidden]]
>>
>> 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