3 ms·
Highly contended queues aren't very common, at least in the kind of programming I do. If contention is extremely high and throughput is paramount, then a lockl
by exDM69 9y ago
Highly contended queues aren't very common, at least in the kind of programming I do.
If contention is extremely high and throughput is paramount, then a lockless solution might work. E.g. audio processing or network stacks might have this kind of usage pattern.
But in my experience, most queues are empty most of the time. That's when you want a lock so the consumer thread can sleep instead of busy wait.
- lomnakkus 9y agoNot to mention: If you thought $OLD_SOLUTION was hard, then lockless is a whole other level of difficulty. (This is why I would generally advocate for a message-passing style for almost everything, but obviously that's not quite the context of this thread. My reasoning is that you can always start off with message passing and if you discover that that's your bottleneck, you can always transition to a faster alternative[1]. Plus, you could use a lock-free message passing solution, e.g. Aeron.) [1] Plus, by using message passing you've already got pretty good separation of logic.