I must have had barriers in there. I knew what they are. I had worked on glibc threads some five years before that (under the maintenance of Ulrich Drepper at the time), using lock-free algorithms, where we had operation like "compare and swap with acquire semantics" (meaning doing the right kind of barrier for acquiring a mutex).

The hardware this was running on supported cache-coherent NUMA, but we didn't use it in that mode; the blades that had multiple nodes ran multiple Linux instances that didn't share memory. Reordering effects at the hardware level weren't observed in the separate mode; if one core wrote to a location A and then B another core would not see the B update before A. Under ccNUMA, had we used it, I believe that would have been an issue.

Compiler reordering is always a threat, so you need at least that __volatile__ __asm__(": : memory"). In the user space infrastructure of that project, I made a library of atomic operations; there must have been barrier macros in there; I can't imagine providing atomic primitives without barriers.