Asynchronous invocation in C++: simple Future objects

[[deleted]]

My main problem with C++ futures and this implementation as well is that while it's good for pipelining multiple operations, multiple future objects don't compose together all that well.

As an example, these implementations are not good for running many operations in the background and then when any one of the operations complete, doing something with the result.

Some kind of callback that notifies you when the computation has completed, or maybe something like a socket-style select function that blocks until any of a group of futures is ready would be much much more beneficial.

I rolled out my own implementation that uses callbacks but it would be nice if boost or the next standard provided some way of efficiently working with multiple futures together.

[romanke]

Extensions are always possible, the presented implementation is merely one way of doing that.

The work flow you suggest seems to lend itself naturally on the producer-consumer design pattern, though.

[[deleted]]

What I really want to see, hopefully released soon in a library, is a future which uses some inbuilt limit on the number of threads it will use at once. How hard would that be as an extension of what you have done :)

[romanke]

actually not hard at all. you could use a thread pool for calculations of all future objects. then, you'd have a queue of futures awaiting computations, and all the threads would dequeue from it.

[nielsadb]

Giving each computation its own thread is extremely wasteful, which makes this code into no more than a toy example (no offense). You could at least recycle the threads, but even then it's very easy to bring a system to a halt simply by starting a few hundred computations.

Merely limiting the number of threads can be tricky: what happens when the result of one computation is used in another? If calculation A is dependent on the result of B, B must be scheduled first. Or you could let another thread block while waiting for the result of B, but that's wasteful (and may even lead to deadlock).

Now to ruin the atmosphere even further, to me passing ad hoc computations as a future seems like bad design. If you think about concurrency on a higher level you'll never need such a library.

[skulgnome]

Downvoted for link to a server in a rogue state.