TAtomicQuasiQueue.h

Go to the documentation of this file.

#pragma once
 
#include <Common/config.h>
 
#include <moodycamel/concurrentqueue.h>
 
#include <cstddef>
#include <iterator>
 
namespace ph
{
 
template<typename T>
class TAtomicQuasiQueue final
{
public:
    TAtomicQuasiQueue();
    explicit TAtomicQuasiQueue(std::size_t initialCapacity);
 
    template<typename U>
    void enqueue(U&& item);
 
    template<std::input_iterator Iterator>
    void enqueueBulk(Iterator firstItem, std::size_t numItems);
 
    template<typename U>
    bool tryEnqueue(U&& item);
 
    bool tryDequeue(T* out_item);
 
    template<std::output_iterator<T> Iterator>
    std::size_t tryDequeueBulk(Iterator out_firstItem, std::size_t numItems);
 
    std::size_t estimatedSize() const;
 
private:
 
#if PH_ENSURE_LOCKFREE_ALGORITHMS_ARE_LOCKLESS
    static_assert(moodycamel::ConcurrentQueue<T>::is_lock_free());
#endif
 
    /*
    `moodycamel::ConcurrentQueue` is lock free and the queue itself is thread-safe, meaning that using
    the queue under multiple producers and multiple consumers will not break the internal state of the
    queue, and all operations generally will not block in any way. However, there are several implications
    due to its design, the most important ones are:
 
    * Items enqueued by each thread will come out in the same order as they were enqueued, however, there
    is no defined item order between threads even with external synchronization. It is FIFO when viewed
    from any single thread, but not FIFO when viewed across threads. Normally this is not an issue, as if
    a total item order is desired, you need some sort of synchronization and might as well just queue into
    a synchronized queue from a single thread.
    See [1] ConcurrentQueue not a FIFO
            https://github.com/cameron314/concurrentqueue/issues/52
        [2] I can't understand how this queue ensure ordering between multiple producer...
            https://github.com/cameron314/concurrentqueue/issues/262
        [3] FIFO guarantees for SPMC usage?
            https://github.com/cameron314/concurrentqueue/issues/309
 
    * Items enqueued on one thread may not be successfully dequeued in another thread, unless there are 
    external means to ensure the enqueue operation is visible on the dequeue thread.
    See [1] [SPMC] externally synchronized try_dequeue fails with items in queue
            https://github.com/cameron314/concurrentqueue/issues/265
        [2] try_enqueue() returns true but approx_size() is always 0 and try_dequeue() fails
            https://github.com/cameron314/concurrentqueue/issues/285
 
    * All the memory effects done by a thread before it enqueues an item will be visible on another
    thread after it dequeues that item. Basic aquire-release semantics are guaranteed. This ensures 
    that all the effects of work done by a thread before it enqueues an element will be visible on 
    another thread after it dequeues that element.
    See [1] sequential consistent
            https://github.com/cameron314/concurrentqueue/issues/73
 
    Most performant case: single-producer multi-consumer.
    */
    moodycamel::ConcurrentQueue<T> m_queue;
};
 
}// end namespace ph
 
#include "Utility/Concurrent/TAtomicQuasiQueue.ipp"