Open JoelFilho opened 4 years ago
Update: boost::lockfree::queue
requires trivially assignable types, so it can't be used with std::tuple
(the pipeline input), and boost::lockfree::spsc_queue
can't be unbounded, so it's not compatible with the current implementation.
Ideally, an unbounded version would be used. In case it's not possible, I'll go back to SPSC queue, and possibly implement a busy wait for full queue, as an "optimistic" version. It would need a similar waiting implementation to pop_unless
to avoid locking on exit.
So, for now, the Boost.LockFree option won't be used.
Do you think that unbounded queues are a good idea at all to support, as this can result in unbounded memory consumption?
Implement a single-producer, single-consumer lock-free queue container and its corresponding policy.
As unbounded queues have reduced real-time applications, the lock-free queue may be bounded.
Interface
(names are placeholders)
Possible issues
pop_unless
.Possible implementations
As lock-free programming is error-prone, an ideal solution would be importing the data structure from a BSL-compatible library.
Boost.LockFree (BSL)The atomic_queue benchmarks point a few other options (not all BSL-compatible) and compares their performance. Could be useful.