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-30 00:07:20

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.