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