Re: [boost] Proposal for a thread synchronisation primitive: future_queue

Subject: Re: [boost] Proposal for a thread synchronisation primitive: future_queue
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2018-04-25 23:47:55

On 25/04/2018 04:01, Martin Hierholzer wrote:
> I want to propose a thread synchronisation primitive, which works 
> like a mixture of (lockfree) queues and futures. Therefore I gave it
>  the name "future_queue". It is basically a lockfree queue which can 
> be waited on for new values (without busy waiting), but it has some
> nice extra features like when_any() and continuations.
> 
> The github project can be found here:
> https://github.com/mhier/future_queue

Looks like a nice concept at first glance (I haven't looked at the 
implementation), although some of those known issues (particularly the 
limited lifespan) would probably need to be solved before it could be 
accepted.

> My first question is, whether this is really something new (I might
have overlooked something in the many boost libraries) and if it makes
sense to integrate it into the boost libraries.

I don't believe there is currently any equivalent, and it is a hole that 
would be nice to fill.

It's not a completely new concept, of course; one of the original future 
proposals included a future_stream that was essentially a recursive 
future -- whenever it completed it produced both a value and another 
future for the next value.  This didn't make it into Boost (or the 
Standard) in the end, though I assume many people have reimplemented 
something similar on their own.

Having said that, the usual thinking on implementing blockable lockfree 
queues doesn't involve futures per se, but rather focuses on using an 
"eventcount" to provide the blocking behaviour as a wrapper around the 
core data structure itself, so it can be used with multiple different 
kinds of queues -- lockfree is usually a balancing act between 
tradeoffs, so different use cases benefit most from different structures.