I was looking over the threading mechanisms in the standard draft. Good to finally get that into the language proper. Although I am disappointed by the apparent lack of a read/write lock, it seems a fairly solid foundation upon which to base additional functionality.
However, I'm not clear on the section about futures. This isn't something I've ever seen before in any language, as far as I can tell. What's the deal with it?
The core concept is to allow a developer to call a function asynchronously (that is have the calling thread continue while the called function executes) and then when you try to use the output of the called functional the calling thread may block until the called function has completed (of course it may have already completed so in some cases neither thread will actually have blocked.)
Oh, so basically lightweight parallelism. I suppose the advantage of using "futures" over simply spawning and then joining to a thread would be that it gives the compiler more options, eg it may simply schedule the function execution within the current thread if that is more efficient?
The futures support in the current C++0x draft does *not* automatically spawn a task to fulfil the future. You have two options:
1) create a promise/future pairing, in which case you must explicitly call set_value() on the promise from some thread in order to make the future "ready"
2) create a packaged_task/future pairing. In this case, the packaged_task wraps a function, and when it is invoked then the future becomes "ready". It is up to you how and when you invoke the packaged_task, though it is designed to be easy to run a packaged_task on a new thread.
In both cases you have to launch any threads, or do something on the current thread to fulfil the future.
Sorry if I added some confusion here, the overview of futures I gave was more of the generic future concept/model, I did not mean to imply that futures are always implemented by spawning exactly one new thread. And thanks Anthony for giving more specific details on the current C++0x draft details (which I skipped.) Overall I think we are all on the same page however – just a different levels of abstraction. Hope this is clear Lindley.