[cpp-threads] RE: "Agenda" for august 23-25 concurrency meeting

[Howard Hinnant]

On Aug 31, 2006, at 1:34 PM, Peter Dimov wrote:

> Howard Hinnant wrote:
>
>> The question I put before us, and strongly recommend that we answer
>> positively is:
>>
>>     For asynchronous function calls, do we offer some mechanism for O
>> (1) performance
>>     of the return type as we do for synchronous function calls?
>>
>>     thread<vector<int> > t = launch_thread(bind(compute, input  
>> data));
>>     vector<int> v = t();  // is this ridiculously expensive?
>
> Is
>
> future< vector<int> > fv = ex.execute( bind( compute, input data ) );
> vector<int> v = fv.move(); // second move() or subsequent op()  
> throws value_already_moved
>
> good enough? It'd work for any asynchronous function call, not just  
> a dedicated thread, but the syntax is a bit clumsier (and the  
> implementation somewhat fragile but doable.)

This design turns what I proposed to make a compile time error into a  
run time error.  It also destroys efficiency for generic code getting  
an asynchronous value.

template <class T, class Pred>
void foo(Pred p)
{
    ...
    T temp = p();  // if asynchronous, inefficiency mandated?
// or:
    T temp = p().move();  // No longer generic, Pred must be a future
    ...
}

I think using the type system will create more robust code.  Clients  
concerned about these kinds of errors could simply forbid futures  
(which are easily searched for), and thus reason more confidently  
about their code.

>> We can have both (copyable) futures and efficient mechanisms for
>> returning heavy values from threads.  We do not have to lock our
>> customers into one design or the other in this engineering tradeoff.
>
> Yes, but... providing two separate and similar mechanisms that  
> essentially do the same thing would be confusing. Moreover, I  
> really wouldn't want us to repeat the boost::thread::join "call  
> exactly once or suffer undefined behavior" mistake. A threading API  
> should appear sequentially consistent and join/wait/operator()  
> ought to be idempotent and race-resilient. Explicitly labelling  
> the .move operation can be considered a feature in this regard.

One can never build efficient code on top of an inefficient base.  If  
there is no efficient layer in the threading API, then we have made  
the performance/feature tradeoff decision for all C++ clients in this  
area.  I'd far rather provide only an efficient base layer upon which  
clients can build their own feature-rich code, than provide only a  
feature-rich (but expensive) API.  If we can provide both layers,  
great (and I think we can).  But there is no question which layer is  
more important for us to provide (imho).

-Howard