# Slow Chat Archives > Slow Chat: C++0x >  Threading mechanisms

## Lindley

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?

----------


## Damien Watkins

Hello

Futures have been around for a number of years in many different programming languages (http://en.wikipedia.org/wiki/Futures_and_promises - and there is a link at the bottom of this page to a list of languages that support them). 

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

Thanks
Damien

----------


## Lindley

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?

That'd make sense.

----------


## anthony_williams

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.

----------


## Damien Watkins

Hello

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.

Thanks
Damien

----------


## Lindley

I guess this is one of those concepts that you have to play around with to understand the value of.

----------

