craflin / lockfreequeue Goto Github PK

Hi,
Let's say I have added to the queue dozens of calls and they are being made.
however the user can turn off the application suddenly.
How do I stop and cancel everything quickly?
i did it like this

//initialize
m_queue = new LockFreeQueue<std::shared_ptr<ThreadMsg>>(n);
...
//destroy
Sleep(1000);
delete m_queue; m_queue = nil;

however, My code is broken at this:

Thank you.

Hello!

Reporting this issue for the public here was on my backlog for ages, so here it is.

A while back I noticed a bunch of crashdumps on Android, where the callstack was pointing to the LockFreeQueueCpp11. I wrote a test that tested the queue in a concurrent setting. It was a single producer single consumer test, starting with syncing the threads up with a busy wait. The pushes and pops were done in a loop to retry on failure. I would produce N integers that then the consumer consumes. Then I check count and order to verify the 'queue-ness'.

On this test, the Google Pixel 3XL device acted up and failed, the counts did not add up. Everything else this unit test ran on was fine, windows, mac, iphones, other android devices. The only thing I could think of back then is that (to my knowledge) all x86 reads are acquire and all writes are release. But honestly most other ARM devices were fine as well, so maybe on that specific SoC this just did not hold this true. And sure enough, as I tightened the memory barriers in the push and pop, the test passed. I went for acq_rel on the CAS operations, and acquires/releases otherwise. I think you can have the CAS weaker than acq_rel, so feel free to investigate.

Now there are many devices using the same specific CPU (Qualcomm SDM845), but I dont think I personally tested more devices on that hw.

I just wanted to let you and the readers know that your milage may vary on ARM, and make sure to have a test for it 👍

Hi, It's like I found a treasure. but when I read you c++ code, one question confused me.

The mpmc_bounded_queue::size method calculate the size of enqueued nodes by acquire-relaxed memory order. What that means?

Getting head by acquire barrier, it easily understand. but why we should use following relaxed memory order to get enqueue_pos_?
I see the c++ spec about relaxed order, which only make sure that instruction is an atomic operation, but can't provide any synchorization. so the enqueue_pos_ variable may be an old value?