In the LF_Queue, the getWriteIndex() might not be thread safe

[sowgali]

In lf_queueu.h, the following function might not be thread-safe because the updateWriteIdx() is called after calling getNextToWriteTo()

auto getNextToWriteTo() noexcept {
      return &store_[next_write_index_];
}

This might lead to two threads accessing the same write location. The same thing applies to reads as well. Let me know if there is anything wrong with my understanding. Should we use a CAS-based lock-free queue, however, it will have to spin. Or we should atomically increment the next_write_index_ with modulus.

[XiaoTonyLuo]

Agree.

In the lf_queue_example.cpp:

    const auto d = lfq->getNextToRead();
    lfq->updateReadIndex();

The read operation and update operation allows re-entry in multi-thread scenario, multiple threads may fetch same content for several times with updating the index for different content. I guess this example just shows the concept of atomic variables but not considering practical problems.