1

In single-consumer/single-producer environments, what are good aspects of boost::lockfree::spsc_queue compared to boost::lockfree::queue?

At first glance, since there can be only a single thread executing an operation, atomic operations will always succeed, which makes lockfree queue's lock-free attribute actually wait-free. (Is that true?)

Then why would we want to use boost::lockfree::spsc_queue at all?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Jangwoong Kim
  • 121
  • 10
  • Presumably it's optimized specifically for that case, so `spsc_queue` might be lower overhead than `queue`, or use less space. Being wait-free vs. lock-free isn't the only criterion, just like two O(n) algorithms can run at different speeds! Also, if the queue is empty or full, it will necessarily block. But with only one writer, you shouldn't have both of those at the same time like you can with a circular buffer with some threads sleeping at unfortunate times. ([Lock-free Progress Guarantees in a circular buffer queue](https://stackoverflow.com/q/45907210)) – Peter Cordes Oct 25 '22 at 13:00

1 Answers1

0

At first glance, since there can be only a single thread executing an operation, atomic operations will always succeed, which makes lockfree queue's lock-free attribute actually wait-free. (Is that true?)

That's a bit like saying "why do we have std::vector, if you can already have std::tuple<size_t, size_t, T*>.

spsc_queue gives you a much more high-level interface, e.g. with storage management (static or dynamic) and batched push/pop. Coming up with these - safely and generically - on your own is not trivial.

That said, sometimes the subset of generic parameters allows for a much simpler implementation that might give you more control/insight. That's a trade-off you can make on your own.

sehe
  • 374,641
  • 47
  • 450
  • 633