Bug in lock-free `SpscFifo::size()` & `SpscFifo::is_full()` method

[elfenpiff]

Bug in lock-free `SpscFifo::size()` & `SpscFifo::is_full()` method

[elBoberido]

@budrus yeah, you are right. I totally overlooked that. this is a complete misuse of the SpscFifo. @elfenpiff do you have a use case for calling size or is_full from another thread than the producer or consumer thread?

[budrus]

@elfenpiff I thought SoFi was an overflowing SPSC queue. With this in mind, would it be OK?. I also have doubts about your fix. You still have the problem as the other threads can change the world between the initial write and read position loads, or?

I think the contract has to be that only one thread changes the write position

[elBoberido]

@budrus you misread the issue title. This is related to the FIFO not the SOFI and the SOFI already has the do-while loop. We just need to port it over.

[budrus]

Ahh, sorry I was coming from #2160 which is about SOFI. But the name is even SpScFiFo so we are talking about single producer + single consumer. My definition of this would be a single thread pushing and a single thread poping. Also not allowing the same publisher or subscriber to be used in more than one thread without something like a memory synchronizing mutex

[elBoberido]

@elfenpiff closing this issue since the calling size and is_full from a different thread than the producer or consumer thread is not supported, at least not when these are running. The information one obtains from these functions is also absolutely useless in a third thread as long as the producer and/or consumer thread are running. If your use case relates to getting these information when either the producer or consumer thread isn't running anymore, then the current logic is safe to use and does not result in the issue you described.