C++ Futures

Jose Michael

I've been hearing about futures for a while. Aside from the fact that there are plenty of old C++ compilers out there that will never support these new features, it's still interesting to see these new additions considering that I said C++ was dead a while back. Uh... that was 2006... January! Three years ago.

Anyhow, I'm doing some unrelated, yet hairy, C++ programming lately. So why not talk about futures too. From this article, which I consider very good in explaining the topic, it looks like you can spawn off computations where you can retrieve the result(s) at a later time.

Does this seem like juggling to anyone? And where have we seen that term used before? Right! With pointers. But now we're gonna be juggling execution. And you can already see in the linked article that the same solutions to pointers are gonna be used with futures.

I understand the need for it. Heck, I'll probably use them myself if I can get a compiler that supports it. But the problems listed at the end of that article are very relevant. Did the C++ committee just decide to avoid what history has taught us these last 20 years?

The funny thing about this is that it resembles what Vladas has been talking about for a while, but with all of the useful things stripped out. No composability. No concurrency. No parallel constructs. No nothing.

I thought I was mistaken with C++ being dead because of the new extensions. But I think that adding features that were never meant to be part of the language is a nail in the coffin. I like C++. It's my favourite language. Well, "like" is perhaps a bit too strong a word. I hate all languages and C++ is the one I hate the least. But I think all current languages, not just C++, are fast approaching the point of no return. You've all seen it. When your program becomes so bloated and has changed so much that a complete rewrite would work better than the alternative. I believe this is called the Big Ball of Mud syndrome.

Time will tell.

C++ Futures

The next C++ standard is supposed to include futures in the libraries. Futures allow assignment to a value that is to be calculated at a later time - assigning a promise in lieu of the final value until such time as it becomes available. The current thread carries on until the value is actually needed, at which time the value is made available or a the thread goes into a wait state. Being a library facility, instead of a built-in language facility as in Oz or Alice-ML, the use of futures is not nearly as transparent. Still, one should be able to get a similar effect. In an article on Broken promises–C++0x futures, Bartosz Milewski criticizes the C++ implementation for it's lack of composability.

What was omitted from the standard, however, was the ability to compose futures. Suppose you start several threads to perform calculations or retrieve data in parallel. You want to communicate with those threads using futures. And here’s the problem: you may block on any individual future but not on all of them. While you are blocked on one, other futures might become ready. Instead of spending your precious time servicing those other futures, you might be blocked on the most time-consuming one. The only option to process futures in order of completion is by polling (calling is_ready on consecutive futures in a loop) and burning the processor.

My personal opinion is that what he is really saying is that concurrency through futures (which in the simple case would be a declarative form of concurreny) don't easily do message-based concurrency. I suppose one could look at CTM and describe how to do Erlang type concurrency with nothing more than dataflow variables. But I think the bigger problem is that we assume that there is a single approach to solving the concurrency problem. We might as well say that STM is good, but it fails to deliver declarative or message concurrency. I personally think languages, either through libraries or built-in language facilities, should provide multiple ways of dealing with concurrency and distribution. Although I don't use C++ anymore, I'm glad that they are integrating lightweight concurrency models into the language.

(Surprised we don't have a category dedicated to concurrency, so I'll post this under parallel/distributed.)

0 Responses to "C++ Futures"

Post a Comment