lib/ovs-atomic-x86_64.h
/*
 * The memory_model_relaxed does not need a compiler barrier, if the
 * atomic operation can otherwise be guaranteed to not be moved with
 * respect to other atomic operations on the same memory location.  Using
 * the 'volatile' keyword in the definition of the atomic types
 * accomplishes this, as memory accesses to volatile data may not be
 * optimized away, or be reordered with other volatile accesses.
 *
 * On x86 also memory_order_consume is automatic, and data dependency on a
 * volatile atomic variable means that the compiler optimizations should not
 * cause problems.  That is, the compiler should not speculate the value of
 * the atomic_read, as it is going to read it from the memory anyway.
 * This allows omiting the compiler memory barrier on atomic_reads with
 * memory_order_consume.  This matches the definition of
 * smp_read_barrier_depends() in Linux kernel as a nop for x86, and its usage
 * in rcu_dereference().
 *
 * We use this same logic below to choose inline assembly statements with or
 * without a compiler memory barrier.
 */
The memory_model_relaxed does not need a compiler barrier, if the
atomic operation can otherwise be guaranteed to not be moved with
respect to other atomic operations on the same memory location.  Using
the 'volatile' keyword in the definition of the atomic types
accomplishes this, as memory accesses to volatile data may not be
optimized away, or be reordered with other volatile accesses.

On x86 also memory_order_consume is automatic, and data dependency on a
volatile atomic variable means that the compiler optimizations should not
cause problems.  That is, the compiler should not speculate the value of
the atomic_read, as it is going to read it from the memory anyway.
This allows omiting the compiler memory barrier on atomic_reads with
memory_order_consume.  This matches the definition of
smp_read_barrier_depends() in Linux kernel as a nop for x86, and its usage
in rcu_dereference().

We use this same logic below to choose inline assembly statements with or
without a compiler memory barrier.
The memory_model_relaxed does not need a compiler barrier if the atomic operation can otherwise be guaranteed to not be moved with respect to other atomic operations on the same memory location . Using the ' volatile ' keyword in the definition of the atomic types accomplishes this as memory accesses to volatile data may not be optimized away or be reordered with other volatile accesses . On x86 also memory_order_consume is automatic and data dependency on a volatile atomic variable means that the compiler optimizations should not cause problems . That is the compiler should not speculate the value of the atomic_read as it is going to read it from the memory anyway . This allows omiting the compiler memory barrier on atomic_reads with memory_order_consume . This matches the definition of smp_read_barrier_depends () in Linux kernel as a nop for x86 and its usage in rcu_dereference () . We use this same logic below to choose inline assembly statements with or without a compiler memory barrier .
static inline void
atomic_compiler_barrier(memory_order order)
{
    if (order > memory_order_consume) {
        compiler_barrier();
    }
}
static inline void atomic_compiler_barrier ( memory_order order ) { if ( order > memory_order_consume ) { compiler_barrier ( ) ; } }
The memory_model_relaxed does not need a compiler barrier, if the
 atomic operation can otherwise be guaranteed to not be moved with
 respect to other atomic operations on the same memory location.
The memory_model_relaxed does not need a compiler barrier if the atomic operation can otherwise be guaranteed to not be moved with respect to other atomic operations on the same memory location .