Memory barriers and Linux kernel spinlock on TILE-Gx

Question

In the Linux kernel spinlock implementation for the TILE-Gx architecture, it looks like they don't issue any memory barriers when locking (only when unlocking):

https://github.com/torvalds/linux/blob/master/arch/tile/include/asm/spinlock_64.h

Then I don't understand why instructions cannot be reordered above the locking, which would cause instructions believed by the programmer to be executed while holding the lock, to actually execute before the lock is taken?

Other architectures seem to have at least a compiler barrier:

• ARM's spinlock has a memory barrier:

  https://github.com/torvalds/linux/blob/master/arch/arm/include/asm/spinlock.h

  With comment:

  A memory barrier is required after we get a lock, and before we 
  release it, because V6 CPUs are assumed to have weakly ordered 
  memory.
  

• And x86's spinlock has a compiler barrier:

  https://github.com/torvalds/linux/blob/master/arch/x86/include/asm/spinlock.h

  With comment:

  barrier();     /* make sure nothing creeps before the lock is taken */
  

Why is TILE-Gx different? I thought its memory model was as weak as ARM's memory model. And why don't they even have a compiler barrier?

Answer 1

The locking function arch_spin_lock uses arch_spin_lock_slow, which in turn uses cmpxchg. The implementation of cmpxchg includes a memory barrier instruction (see http://lxr.free-electrons.com/source/arch/tile/include/asm/cmpxchg.h).