[cpp-threads] Asynchronous Function Proposal

[Bjarne Stroustrup]

Robison, Arch wrote:
> Programmers need some way to reason about the space/time complexity, otherwise they cannot depend upon the facility to deliver reasonable performance.    
>
> Being able to reason about the properties of nested parallelism is important because in large scale software, a component does not always know whether it is "top level" or deeper in the parallelism tree.
>
> - Arch
>   


We should remember that we are not trying to design and standardize a 
parallel programming system/library; we are trying to provide a 
primitive mechanism to allow others to build such libraries/systems.

Trying to provide a complete high-level parallel programming library is 
not just beyond us in the time available and (IMO) premature, but also 
against our agreement on how to proceed (spend our precious little time) 
"the Kona compromise." To contrast, I consider providing a mechanism, 
async(), both feasible and within the Kona compromise. Kudos to Lawrence 
for taking the initiative.

>   

> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf Of Herb Sutter
> Sent: Wednesday, June 03, 2009 1:36 AM
> To: C++ threads standardisation; Boehm, Hans; Lawrence Crowl; Bjarne Stroustrup
> Cc: Pablo Halpern
> Subject: Re: [cpp-threads] Asynchronous Function Proposal
>
> Popping the stack a little: Does this matter for async()?
>
>
> With async(), all we're trying to do is specify a way to say code can be executed asynchronously, with control over whether that's guaranteed to happen on another thread or not. As far as work-stealing implementation goes, the most we're interested in is permitting a work-stealing implementation, not requiring one.
>
> We're not trying to guarantee the big-Oh performance of heavily scalable code (which people are only beginning to be able to write in the mainstream anyway), are we? Is the main concern then interaction with thread_local lifetime (which issues largely exist with or without async) or on the thread/future proposals (which again are just helping refine those proposals, as they ought to be usable for building something as simple as a basic "async()" that might or might not run on the same thread)?
>
> Herb
>
>
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>