我发现Linux内核中的自旋锁现在都使用“ticket-based”自旋锁。然而，在查看它的ARM实现之后，我感到困惑，因为“load-add-store”操作根本不是原子操作。请参阅以下代码：
74 static inline void arch_spin_lock(arch_spinlock_t *lock)
75 {
76 unsigned long tmp;
77 u32 newval;
78 arch_spinlock_t lockval;
79
80 __asm__ __volatile__(
81 "1: ldrex %0, [%3]\n" /*Why this load-add-store is not atomic?*/
82 " add %1, %0, %4\n"
83 " strex %2, %1, [%3]\n"
84 " teq %2, #0\n"
85 " bne 1b"
86 : "=&r" (lockval), "=&r" (newval), "=&r" (tmp)
87 : "r" (&lock->slock), "I" (1 << TICKET_SHIFT)
88 : "cc");
89
90 while (lockval.tickets.next != lockval.tickets.owner) {
91 wfe();
92 lockval.tickets.owner = ACCESS_ONCE(lock->tickets.owner);
93 }
94
95 smp_mb();
96 }
如您所见，在第81~83行，它将lock-＆gt; slock加载到“lockval”并将其递增1，然后将其存储回lock-＆gt; slock。
然而，我没有看到任何地方确保这是原子的。所以有可能：
不同cpu上的两个用户同时读取lock-＆gt; slock到他们自己的变量“lockval”;然后他们分别将“lockval”加一个然后再存储。
这将导致这两个用户拥有相同的“号码”，一旦“所有者”字段成为该号码，他们都将获得锁并对某些共享资源进行操作！
我不认为内核可以在spinlock中出现这样的错误。我错了吗？
答案 0 :(得分：2)
STREX is a conditional store，此代码具有Load Link-Store Conditional语义，即使ARM不使用该名称。
操作要么以原子方式完成，要么失败。
汇编程序块测试失败（tmp变量指示失败）并使用新值（由另一个核心更新）重新尝试修改。