Speicherbarrieren und Linux-Kernel spinlock auf TILE-Gx

Question

im Linux-Kernel spinlock Implementierung für die TILE-Gx-Architektur, es sieht aus wie sie alle Speicherbarrieren geben keine beim Sperren (nur beim Entriegeln):

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

Dann verstehe ich nicht, warum Anweisungen nicht über der Sperrung neu geordnet werden können, was dazu führen würde, dass Anweisungen, die der Programmierer für ausgeführt hält, die Sperre tatsächlich ausgeführt werden, bevor die Sperre ausgeführt wird?

Andere Architekturen scheinen zumindest einen Compiler Barriere zu haben:

• ARM spinlock verfügt über einen Speicher Barriere:

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

  Mit Kommentar:

  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. 
  

• Und spinlock x86 hat eine Compiler-Barriere:

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

  Mit Kommentar:

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

Warum ist TILE-Gx anders? Ich dachte, sein Speichermodell sei so schwach wie ARMs Speichermodell. Und warum haben sie nicht einmal eine Compiler-Barriere?

Answer 1

Die Sperrfunktion arch_spin_lock verwendet arch_spin_lock_slow, die wiederum cmpxchg verwendet. Die Implementierung von cmpxchg enthält eine Speicherbarrierenanweisung (siehe http://lxr.free-electrons.com/source/arch/tile/include/asm/cmpxchg.h).