0

I need to simulate a scenario where blocking algorithms are faster than their non-blocking counterparts, mainly due to the overhead that the latter incur. I'm thinking about using Java's LinkedBlockingQueue and ConcurrentLinkedQueue for this scenario.

Can anyone suggest a scenario where LinkedBlockingQueue is faster than ConcurrentLinkedQueue?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Michael
  • 23
  • 5
  • Too low rep to comment, but maybe this helps: https://stackoverflow.com/questions/49843012/why-use-concurrentlinkedqueue-when-we-have-linkedblockingqueue –  Jul 20 '21 at 09:31
  • Related: https://stackoverflow.com/questions/5680869/do-lock-free-algorithms-really-perform-better-than-their-lock-full-counterparts – Hulk Jul 20 '21 at 09:50
  • 1
    It depends a bit what you define as "outperform" - e.g. lock-free algorithms may produce higher CPU load, while still increasing throughput. You could try the single-threaded edge-case as a scenario where the added cost of the lock-free implementation yields no benefit. – Hulk Jul 20 '21 at 09:59
  • Perhaps really high contention, especially from more threads than you have cores if the backoff mechanism are different for locks vs. whatever `ConcurrentLinkedQueue` does. Lock-free algorithms are often good when contention is low-ish so it's rare to actually have to retry. (The opposite of what happens when people microbenchmark with n threads hammering on something without doing any other real work in between). – Peter Cordes Jul 20 '21 at 21:47

0 Answers0