[cpp-threads] Asynchronous Function Proposal

[Herb Sutter]

Everything you say is true and important, but it doesn't apply to async(). That's what I thought we were losing sight of a bit here, so let me try to summarize the intended focus.

async() isn't meant to be The Answer (or even An Answer) for nested parallelism, performance, or scalability. async() is about just providing a single simple way to easily perform an async call and get an async result, without all the packaged_task boilerplate people have to write otherwise in the current draft. It is mostly about concurrency rather than parallelism, but there seems to me to be no reason to not also permit running a task on a work stealing implementation, and the only hook I've been pushing for to permit that is to have the default be "might or might not run on this thread."

That's all we're looking at for now. In time (TR2 or C++1x), at the same time we consider things such as thread pools, we know we probably do want to support more advanced uses including nested parallelism and performance and scalability. We already know that to do that we'd need to add lots of other stuff, such as the task_groups PPL exposes and performance knobs such as some TBB exposes. This async() isn't meant to be that, that's all.

Herb


> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk [mailto:cpp-threads-
> bounces at decadentplace.org.uk] On Behalf Of Robison, Arch
> Sent: Wednesday, June 03, 2009 7:55 AM
> To: C++ threads standardisation; Boehm, Hans; Lawrence Crowl; Bjarne
> Stroustrup
> Subject: Re: [cpp-threads] Asynchronous Function Proposal
> 
> 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
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads