Cameron
As I said, this breaks the public API, so I can't merge this as-is, sorry.
Right, not really feasible with the current design. Yes, this could be done for `std::atomic` integers, though the reader/writer indexes would need to be coordinated somehow.
Data loss should not be possible. Interestingly, starvation is possible, as dequeue is [not fair](https://github.com/cameron314/concurrentqueue/blob/9dc1b2cfcad03b4ee22ea57ddb5c453c41c19ac9/concurrentqueue.h#L1231). However, using the version that accepts a consumer token should be fair in this scenario....
Probably best to avoid short-lived producer tokens. But using a consumer token will cause the consumer to cycle between the inner producer sub-queues. Without the token, the consumer just picks...
Right. You can use just producer tokens, just consumer tokens, neither, or both. Creating/destroying a producer token has significant overhead. Instead of churning producer tokens, consider using a thread-local (dispatcher-local?)...
CMake support was provided by the community. I don't use CMake for developing locally, and I'm not particularly familiar with it. Will this change break existing code that uses the...
Are two or more threads enqueueing concurrently? Are two or more threads dequeueing concurrently? Please provide a sample that reproduces the problem.
Not much has changed code-wise. I have been busy, sorry. I will eventually make another release.
Neat, thanks! Do the tests and benchmarks compile using the makefiles in those directories? (May need to replace `g++` with `clang++`.)
Don't waste your time, the spsc implementation depends specifically on x86 semantics and is not portable. I guess we'd have to disable it completely to be able to run the...