ARM 上的无锁 SPSC 队列实现

Question

I'm trying to write a single producer single consumer queue for ARM and I think I'm close to wrapping my head around DMB, but need some checking (I'm more familiar with std::atomic.)

Here's where I'm at:

bool push(const_reference value)
{
    // Check for room
    const size_type currentTail = tail;
    const size_type nextTail = increment(currentTail);
    if (nextTail == head)
        return false;

    // Write the value
    valueArr[currentTail] = value;

    // Prevent the consumer from seeing the incremented tail before the
    // value is written.
    __DMB();

    // Increment tail
    tail = nextTail;

    return true;
}

bool pop(reference valueLocation)
{
    // Check for data
    const size_type currentHead = head;
    if (currentHead == tail)
        return false;

    // Write the value.
    valueLocation = valueArr[currentHead];

    // Prevent the producer from seeing the incremented head before the
    // value is written.
    __DMB();

    // Increment the head
    head = increment(head);

    return true;
}

My question is: is my DMB placement and justification accurate? Or is there still understanding that I'm missing? I'm particularly uncertain about whether the conditionals need some guard when dealing with the variable that's updated by the other thread (or interrupt).

Answer 1

• A barrier there is necessary but not sufficient, you also need "acquire" semantics for loading the var modified by the other thread. (Or at least consume , but getting that without a barrier would require asm to create a data dependency. A compiler wouldn't do that after already having a control dependency.)
• A single-core system can use just a compiler barrier like GNU C asm("":::"memory") or std::atomic_signal_fence(std::memory_order_release) , not dmb . Make a macro so you can choose between SMP-safe barriers or UP (uniprocessor) barriers.
• head = increment(head); is a pointless reload of head , use the local copy.
• use std::atomic to get the necessary code-gen portably.

---

You normally don't need to roll your own atomics; modern compilers for ARM do implement std::atomic<T> . But AFAIK, no std::atomic<> implementations are aware of single-core systems to avoid actual barriers and just be safe wrt. interrupts that can cause a context switch.

On a single-core system, you don't need dsb , just a compiler barrier. The CPU will preserve the illusion of asm instructions executing sequentially, in program order. You just need to make sure the compiler generates asm that does things in the right order. You can do that by using std::atomic with std::memory_order_relaxed , and manual atomic_signal_fence(memory_order_acquire) or release barriers. (Not atomic_thread_fence ; that would emit asm instructions, typically dsb ).

---

Each thread reads a variable that the other thread modifies. You're correctly making the modifications release-stores by making sure they're visible only after access to the array.

But those reads also need to be acquire-loads to sync with those release stores . Eg to make sure push isn't writing valueArr[currentTail] = value; before pop finishes reading that same element. Or reading an entry before it's fully written.

Without any barrier, the failure mode would be that if (currentHead == tail) return false; doesn't actually check the value of tail from memory until after valueLocation = valueArr[currentHead]; happens. Runtime load reordering can easily do that on weakly-ordered ARM. If the load address had a data dependency on tail , that could avoid needing a barrier there on an SMP system (ARM guarantees dependency ordering in asm; the feature that mo_consume was supposed to expose). But if the compiler just emits a branch, that's only a control dependency, not data. If you were writing by hand in asm, a predicated load like ldrne r0, [r1, r2] on flags set by the compare would I think create a data dependency.

Compile-time reordering is less plausible, but a compiler-only barrier is free if it's only stopping the compiler from doing something it wasn't going to do anyway.

---

untested implementation, compiles to asm that looks ok but no other testing

Do something similar for push . I included wrapper functions for load acquire / store release, and fullbarrier(). (Equivalent of Linux kernel's smp_mb() macro, defined as a compile time or compile+runtime barrier.)

#include <atomic>

#define UNIPROCESSOR


#ifdef UNIPROCESSOR
#define fullbarrier()  asm("":::"memory")   // GNU C compiler barrier
                          // atomic_signal_fence(std::memory_order_seq_cst)
#else
#define fullbarrier() __DMB()    // or atomic_thread_fence(std::memory_order_seq_cst)
#endif

template <class T>
T load_acquire(std::atomic<T> &x) {
#ifdef UNIPROCESSOR
    T tmp = x.load(std::memory_order_relaxed);
    std::atomic_signal_fence(std::memory_order_acquire);
    // or fullbarrier();  if you want to use that macro
    return tmp;
#else
    return x.load(std::memory_order_acquire);
    // fullbarrier() / __DMB();
#endif
}

template <class T>
void store_release(std::atomic<T> &x, T val) {
#ifdef UNIPROCESSOR
    std::atomic_signal_fence(std::memory_order_release);
    // or fullbarrier();
    x.store(val, std::memory_order_relaxed);
#else
    // fullbarrier() / __DMB(); before plain store
    return x.store(val, std::memory_order_release);
#endif
}

template <class T>
struct SPSC_queue {
  using size_type = unsigned;
  using value_type = T;
  static const size_type size = 1024;

  std::atomic<size_type> head;
  value_type valueArr[size];
  std::atomic<size_type> tail;  // in a separate cache-line from head to reduce contention

  bool push(const value_type &value)
  {
    // Check for room
    const size_type currentTail = tail.load(std::memory_order_relaxed);  // no other writers to tail, no ordering needed
    const size_type nextTail = currentTail + 1;    // modulo separately so empty and full are distinguishable.
    if (nextTail == load_acquire(head))
        return false;

    valueArr[currentTail % size] = value;
    store_release(tail, nextTail);
    return true;
  }
};

// instantiate the template for  int  so we can look at the asm
template bool SPSC_queue<int>::push(const value_type &value);

Compiles cleanly on the Godbolt compiler explorer with zero barriers if you use -DUNIPROCESSOR , with g++9.2 -O3 -mcpu=cortex-a15 (just to pick a random modern-ish ARM core so GCC can inline std::atomic load/store function and barriers for the non-uniprocessor case.