Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Futures for C++11 at Facebook

code.facebook.com

Post reply on HN
Print view View original

31–40 of 84 posts

Re: Futures for C++11 at Facebook

#31

Post by millstone »

wcummings wrote: post #25
millstone wrote: post #19

I've never programmed seriously with futures, and I'm a little apprehensive. For example, let's say I type the string "123". If there's a future / promise / async whatever anywhere, we risk processing the characters out of order. We may not catch that in testing, because it's usually fast enough that it comes out in the right order. > It is more efficient to make service A asynchronous, meaning that while B is busy c…

Are you asking "how do you do concurrent programming?" These problems aren't specific to promises.

I don't think so. Here's a concrete example of what I mean.

Say we are making a Todo list app. We have a list of Pending and a list of Completed todos, and when the user completes one, we move it from Pending to Completed. But how do we ensure other threads can't see the transient in-between state? Traditional concurrent programming might solve this with a lock:

    lock()
    Pending.remove(todo)
    Completed.add(todo)
    unlock()
This problem is very well known, and any discussion of threads will spend a lot of time on locks, queues, serialization techniques, etc. for avoiding races. Now, with futures:

    Pending.remove(todo).then({Completed.add(todo)})
We've got the analogous race condition, even if we're single threaded. But articles on Futures never seem to discuss techniques for mitigating this. Why not? Is there a Futures equivalent for a lock?

Re: Futures for C++11 at Facebook

#32

Post by batou »

amelius wrote: post #13

But how does one elegantly stop a chain of futures from executing when one is no longer interested in the final outcome of this chain of futures?

In microsoft-land where I reside, they are called tasks and we cancel tasks.

Technically all tasks can be collected in a list and then you just cancel everything in the list but I have yet to find a scenario where I've needed this.

Re: Futures for C++11 at Facebook

#33

Post by teraflop »

millstone wrote: post #31
wcummings wrote: post #25

Earlier quoted context omitted.

Are you asking "how do you do concurrent programming?" These problems aren't specific to promises.

I don't think so. Here's a concrete example of what I mean. Say we are making a Todo list app. We have a list of Pending and a list of Completed todos, and when the user completes one, we move it from Pending to Completed. But how do we ensure other threads can't see the transient in-between state? Traditional concurrent programming might solve this with a lock: lock() Pending.remove(todo) Completed.add(todo) unlock(…

Futures are used when you want to do something asynchronously -- that is, you want the action to happen in the background and be notified after it completes. If you want actions to take place atomically, then why make them asynchronous? Nobody ever said that all code blocks of the form "A; B" should be replaced with "A.then(B)".

If you're writing in C++ with shared data structures accessible from multiple threads, you need locks anyway; futures don't change that. If you're writing in Javascript, your code is inherently single-threaded and no locks are necessary.

Re: Futures for C++11 at Facebook

#34

Post by hatred »

bklimt wrote: post #20

How does this project relate to Facebook's other futures/promises library, Bolts? https://code.facebook.com/posts/225525624316574/building-and...

They might look related in terms of various "idioms/building blocks" used but they cater to two completely different programming languages i.e. Objective C/C++.

Re: Futures for C++11 at Facebook

#35

Post by millstone »

teraflop wrote: post #33
millstone wrote: post #31

Earlier quoted context omitted.

I don't think so. Here's a concrete example of what I mean. Say we are making a Todo list app. We have a list of Pending and a list of Completed todos, and when the user completes one, we move it from Pending to Completed. But how do we ensure other threads can't see the transient in-between state? Traditional concurrent programming might solve this with a lock: lock() Pending.remove(todo) Completed.add(todo) unlock(…

Futures are used when you want to do something asynchronously -- that is, you want the action to happen in the background and be notified after it completes. If you want actions to take place atomically, then why make them asynchronous? Nobody ever said that all code blocks of the form "A; B" should be replaced with "A.then(B)". If you're writing in C++ with shared data structures accessible from multiple threads, yo…

> If you want actions to take place atomically, then why make them asynchronous?

This is usually up to the API you are using. You may not have a choice.

> your code is inherently single-threaded and no locks are necessary

Locks are necessary in the single threaded case. See my example:

    Pending.remove(todo).then({Completed.add(todo)})
Nothing prevents another operation from executing between the remove() and add() calls, and seeing the transient state. You need the analog of a lock to prevent that. What is that with Futures?

Re: Futures for C++11 at Facebook

#36

Post by damart »

Futures/promises seem like they're basically just a limited subset of FRP (Rx, RAC) observables/streams - such that they either "next" once and "complete", or "error" without "nexting".

I suppose they also have caching built in, but that is easy to build on top of FRP.

Re: Futures for C++11 at Facebook

#37

Post by blakesmith »

I'm a huge fan of Finagle futures, which this project seems to draw a lot of inspiration from. My biggest challenge is actually the fact that Folly as a dependency is so heavyweight memory wise: I have trouble building anything on my laptop with 4 gigabytes of memory. Most of the Folly code is template code - I guess lots of template code leads to large memory compile time footprints?

Anyway - great project. I'd love to use it sometime maybe when I get a bigger dev machine.

Re: Futures for C++11 at Facebook

#38

Post by teraflop »

millstone wrote: post #35
teraflop wrote: post #33

Earlier quoted context omitted.

Futures are used when you want to do something asynchronously -- that is, you want the action to happen in the background and be notified after it completes. If you want actions to take place atomically, then why make them asynchronous? Nobody ever said that all code blocks of the form "A; B" should be replaced with "A.then(B)". If you're writing in C++ with shared data structures accessible from multiple threads, yo…

> If you want actions to take place atomically, then why make them asynchronous? This is usually up to the API you are using. You may not have a choice. > your code is inherently single-threaded and no locks are necessary Locks are necessary in the single threaded case. See my example: Pending.remove(todo).then({Completed.add(todo)}) Nothing prevents another operation from executing between the remove() and add() cal…

Sorry, maybe I was unclear. Let me try again from a different angle: It's up to an API designer to come up with a sane API, including sane usage of futures/promises only where it makes sense.

In the browser world, futures or promises are an abstraction over some operation that doesn't block the UI thread, and therefore can allow some other work to happen in the meantime. In your example, if Pending and Completed provide an interface to some remote API, then a lock provides no benefit because making separate RPCs can't possibly be atomic anyway. If they're operating on local data or the DOM, then making them return futures is pointless because the work will happen on the same thread, and no other code could possibly observe the intermediate state anyway. (This is a core principle of the browser event loop: Javascript code is never preempted, it can only yield control by running to completion. Apologies if I'm repeating stuff you already know.)

In other languages, futures are more flexible because they can contain CPU-bound work that operates on shared memory. In that case, futures don't magically absolve you of the need to protect that shared memory. But if you have multiple operations on the same shared data, it once again doesn't normally make sense to decouple them with futures in the first place.

Re: Futures for C++11 at Facebook

#39

Post by dbattaglia »

obstinate wrote: post #2

I'm totally on board with futures, IF your application needs to scale to the point that blocking, threaded computation is infeasible. However, I honestly don't think that's the case for most folk. Blocking, direct-call computation is way simpler than futures.

I think the language and framework are also important in deciding to use them or now. In modern C# with MVC/WebAPI it feels wrong to me to NOT use async/await/Task (the .Net version of Futures and Promises). For fairly little change in coding style you can get some big performance wins on IO code.

Re: Futures for C++11 at Facebook

#40

Post by codesushi42 »

millstone wrote: post #35
teraflop wrote: post #33

Earlier quoted context omitted.

Futures are used when you want to do something asynchronously -- that is, you want the action to happen in the background and be notified after it completes. If you want actions to take place atomically, then why make them asynchronous? Nobody ever said that all code blocks of the form "A; B" should be replaced with "A.then(B)". If you're writing in C++ with shared data structures accessible from multiple threads, yo…

> If you want actions to take place atomically, then why make them asynchronous? This is usually up to the API you are using. You may not have a choice. > your code is inherently single-threaded and no locks are necessary Locks are necessary in the single threaded case. See my example: Pending.remove(todo).then({Completed.add(todo)}) Nothing prevents another operation from executing between the remove() and add() cal…

A future or promise is not a replacement for locks and mutexes. They are intended to abstract async operations for lazy evaluation and intend to fix the problem of "callback hell" that occurs when chaining async operations and response handlers.

Futures and promises make more sense in functional languages because they don't have a shared memory model, which avoids having to share resources between parallel tasks using locks. Google dataflow programming for more insight into how lazy evaluation and referential transparency parallelize work when there's no mutable state.

Post reply on HN