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:
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk