Scaling Synchronization in Multicore Programs
queue.acm.org
queue.acm.org
A single MPSC queue per core works very well and this is what VoltDB does. For most sane task sizes this works fine and it scales because you can only process so many tasks at a single core so queue contention isn't an issue.
If you want to crank things to 11 you can do an SPSC queue between every core, and this is what ScyllaDB does and is suggested in the article. This does relieve CAS failure, but outside of microbenchmarks I am not sure it is a real world issue.
I had never considered the advantages of atomic instructions that never fail. In the context of things like Disrupor or Agrona those choices start to make more sense.
A single queue is only being asked to handle low hundreds of thousands of events per second which isn't that much. This occurs because there is substantial (for some definition of substantial) work associated with each task. If you are looking up a value in a hash map then yes it matters, but if you are doing something more substantial it doesn't matter. The research is definitely interesting and it solves real world problems, but I don't think you necessarily need to move to groups of input task queues directly.
If you look at the graph it's at five million operations/second and 1 CAS with two threads. If you aren't going to push more than 1 million ops through a single queue/core I think you will be fine.