[cpp-threads] Asynchronous Function Proposal

[Robison, Arch]

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

-----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