AbstractFifo single consumer/single producer (thread safety)?

Seems like I should know the answer from reading the documentation (maybe I‘m just to blind!) but I seriously couldn‘t find it.

Would be great to have a short answer on this topic!
Thanks.

I believe the answer to this is it depends on how you manage the calls to: void finishedRead (int numRead)

Although not positive what you’re asking – anyone can read/write to it – you have control over who sets & receives data flexibly since you can read at any point without marking things as “consumed” – but not sure a case you’d want multiple producers

I use it often to manage overlap add – i.e.:

fifo.read(bufferSize)
fifo.finishedRead(hopSize)

Could you put the question in a full sentence?
Hard to guess from the title.
But if I guess right, AbstractFIFO is single producer / single consumer only.
It fills up and doesn’t cope when it is full and isn’t consumed with the same speed.

Does that answer the question?

Yes it does. Sorry it was a little late yesterday. You were right the question was, Is the AbstractFifo a single consumer/single producer fifo. Would that be something to put in the documentation? I feel like it is quite an important information for a thread safe fifo queue

You know I see this term thrown around quite a bit and never seem to find a good explanation on what single producer single consumer means, what would be a non single/single circular buffer?

It means that only one thread is allowed to push data and only one thread is allowed to pop data. That is an important boundary considering that there might be multiple Audiothreads working on the same graph.

1 Like

An example would be a multi tap delay, where one signal is produced, but several taps read from different read positions.
The main difference is that now with reading the data is not consumed but stays available for other consumers.
Or did I get it wrong?

Maybe there is a different data structure that does what you want, but it was not what I was asking. I didn‘t know there was a different way to interpret that aside from thread safety (I adjusted the title) but let me clarify what my question is about:

For a lock free fifo, there is an important trait to talke about: single vs multi consumer and single vs multi producer (so there are in total four possible variations). A multi consumer/multi producer fifo doesn‘t change anything about the behavior. Its basically still a list, with one push and one pop function. What changes is, how thread safe the fifo queue is. Are multiple threads allowed to call push concurrently and are multiple threads allowed to call pop concurrently. Push and pop should be allowed to called concurrently all the time, otherwise it would defeat the purpose.

So as far as I understand the class AbstractFifo is a single consumer / single producer lock free fifo queue?

The read and write indices are atomic, so it is safe to be accessed from any thread.
BUT: when one thread starts a pop operation it gets the read index, does something and only when calling finishedRead() or when ScopedRead goes out of scope the read index is advanced.
For a real multi consumer scenario like the one you mentioned you would need to atomically fetch and advance the read index, so the next thread doesn’t fetch the same data.

I think the AbstractFIFO is not as general purpose as you want it. The main benefit I see in AbstractFIFO is the way it copies buffers to and from using vectorised methods like audioBuffer.copyFrom()

At first view (from the documentation) it seems to be a ring/circular buffer.
And it is claimed to be lock-free for single-reader, single-writer.

1 Like