# Concurrent queue

I recently wrote a concurrent, mutex-less (but not lockfree) queue and wanted to know if it is actually correct, and if there are any particular improvements I could make:

template <typename T>
class concurrent_queue
{
protected:
T *storage;
std::size_t s;

union alignas(16) dpointer
{
struct
{
T *ptr;
std::size_t cnt;
};
__int128 val;
};

dpointer consumer_pending, producer_pending;

public:
concurrent_queue(std::size_t s): storage(nullptr)
{
storage = static_cast<T*>(::operator new((s+1)*sizeof(T)));

__atomic_store_n(&(consumer_pending.val), (dpointer{storage, 0}).val, __ATOMIC_SEQ_CST);

__atomic_store_n(&(producer_pending.val), (dpointer{storage, 0}).val, __ATOMIC_SEQ_CST);
this->s = s + 1;
}
~concurrent_queue()
{
{
}
::operator delete(storage);
}

template <typename U>
bool push(U&& e)
{
while(true)
{
dpointer a;
auto next = a.ptr + 1;
if(next == storage + s) next = storage;

if(next == b) return false;
dpointer newval{next, a.cnt+1};
if(!__atomic_compare_exchange_n(&(producer_pending.val), &(a.val), (newval.val), true, __ATOMIC_ACQUIRE, __ATOMIC_RELAXED)) continue;

new (a.ptr) T(std::forward<U>(e));

return true;
}
}

template <typename U>
bool pop(U& result)
{
while(true)
{
dpointer a;
auto next = a.ptr + 1;
if(next == storage + s) next = storage;

if(a.ptr == b) return false;
dpointer newval{next, a.cnt+1};
if(!__atomic_compare_exchange_n(&(consumer_pending.val), &(a.val), (newval.val), true, __ATOMIC_ACQUIRE, __ATOMIC_RELAXED)) continue;

result = std::move(*(a.ptr));
(a.ptr)->~T();

return true;
}
}
};


It's platform specific to GCC on x86_64 and a CPU that supports double width CAS right now, but I assume it wouldn't be that hard to adjust it for other platforms.

I've stress tested it with multiple threads pushing and popping, with both POD types and with memory-managing types like std::vector and haven't had any issues so far...before I put in the double width CAS I encountered the ABA problem and had segmentation faults, but with it it seems to be fine.

However, I'm new to all this multithreaded stuff, and wanted someone more experienced than me to tell me if this would work, say, on a system with a weak memory model.

• "It's platform specific to GCC on x86_64 [...]" Ok, but can we move away from that? – edmz Jun 5 '14 at 9:03
• @black of course; for 32 bit systems just use a uint64_t instead of __int128, for LL/SC systems a counter isn't even necessary, and for other compilers use the respective equivalent intrinsics. Though, if my memory fences aren't correct it won't work on some systems – chbaker0 Jun 5 '14 at 12:01

Regarding the conditional return types in push() and pop(), it may be clearer to use a different type of infinite loop, such as a for(;;). This will better focus the attention to the loop contents.

You could also use curly braces for the single-line statements. Some of these lines are quite long, so the executed code is at the very end. This should also help distinguish them from the busy-waits.