Are enqueue operations in the blockingconcurrentqueue lock-free?

[maxmilne]

I'm thinking about at a simple SPSC scenario (audio callbacks which aren't supposed to block or allocate memory, which seems to have motivated some of this work based on the blog posts). I don't understand atomic operations very well at all, so it's hard for me to tell from the code, but do enqueue operations in blockingconcurrentqueue also block, or is do only wait_dequeue() calls block?

I ask because if the enqueue operations are blocking, it seems like for the audio callback scenario (where you're forwarding audio input out of the callback via this queue) you've got no choice but to busy wait on the consumer side.

[cameron314]

Enqueue operations do not block, but some may allocate additional memory. They are not wait-free. For SPSC, consider using my ReaderWriterQueue instead.

[maxmilne]

Thanks. So enqueue operations on ReaderWriterQueue are wait free even when using blocking wait_dequeue operations?

(I initially leaned towards using this repository over ReaderWriterQueue because of the bulk operations, which seem better if you need to copy a bunch of individual floats from an audio buffer, but I could also just use pre-allocated float arrays or something.)

[cameron314]

ReaderWriterQueue enqueue may also allocate memory as needed.

So enqueue operations on ReaderWriterQueue are wait free even when using blocking wait_dequeue operations?

They are non-blocking. Specifically, the tryenqueue methods of each queue do not allocate and are lock-free (but not necessarily wait-free). The wait methods are blocking.

For SPSC audio stuff you probably want to use the BlockingReaderWriterCircularBuffer instead. Whether you use try_enqueue or wait_enqueue is up to you.

I'd be surprised if ConcurrentQueue with bulk operations wins out but it's not impossible; depends how it's used I suppose.

[maxmilne]

Perfect, thanks so much for the detailed answer.