On 27/04/2018 05:12, Martin Hierholzer wrote:
This sounds like a very similar concept indeed, but I cannot find anything about this on the web. Maybe the future_queue is a bit different in the sense that one can have multiple ready values in the queue, just like in any normal fifo queue.
The recursive futures support that too, in the sense that when it returns a "next" future it might already have a completed value which can be extracted synchronously without blocking. There's an example in this post https://lists.boost.org/Archives/boost/2007/03/118742.php. Of course, it relies on futures, shared_ptrs, and memory allocations, which might be too heavyweight for some usages. But it's also trivial to implement around those existing types, which is probably why it didn't end up making it into the standard as a separate type.
On a second thought, maybe I could even change the implementation of the future_queue to internally use e.g. the well-known boost::lockfree queues together with some semaphore to implement the blocking behaviour. I am not 100% sure yet, but I think all current features could be implemented by that. Do you think this would improve the implementation? It might be a bit simpler and maybe even more efficient in some cases.
I would love to see a portable eventcount (http://www.1024cores.net/home/lock-free-algorithms/eventcounts) implementation in Boost.Lockfree.