大多数'无锁'代码其实不是无锁的
内容提要
大多数自称“无锁”的代码并不符合无锁定义，尤其在ARM架构上存在数据竞争问题。无锁编程需满足严格的进展保证，确保系统不被单个线程阻塞，正确的内存顺序和ABA问题处理也至关重要。通常情况下，使用锁比无锁更可靠且易于维护。
关键要点
-
大多数自称“无锁”的代码并不符合无锁定义，尤其在ARM架构上存在数据竞争问题。
-
无锁编程需满足严格的进展保证，确保系统不被单个线程阻塞。
-
正确的内存顺序和ABA问题处理也至关重要。
-
使用锁通常比无锁更可靠且易于维护。
-
Lock-free的定义强调系统整体的前进保证，而不仅仅是没有使用锁。
-
在ARM架构上，memory_order_relaxed的使用可能导致数据竞争和不一致性。
-
CAS操作需要防止ABA问题，常用的解决方案包括Tagged pointer和Hazard Pointer。
-
在大多数场景下，使用mutex和合理的锁粒度比无锁更优。
-
真正需要无锁的场景包括信号处理、内核中断上下文和极端延迟要求。
-
无锁编程的复杂性和潜在错误使得在大多数情况下使用锁更为明智。
延伸问答
什么是无锁编程的严格定义？
无锁编程的严格定义是系统整体保证前进，至少有一个线程能在有限步内完成操作，即使其他线程被阻塞或抢占。
在ARM架构上使用无锁代码时可能遇到什么问题？
在ARM架构上，使用无锁代码可能导致数据竞争和不一致性，尤其是使用memory_order_relaxed时。
为什么在大多数情况下使用锁比无锁更可靠？
使用锁通常更可靠，因为无锁代码的错误难以发现，且维护性较差，而锁的正确性更容易推理。
什么是ABA问题，如何解决？
ABA问题是指在CAS操作中，无法区分值是否在操作间被改变。解决方案包括使用Tagged pointer和Hazard Pointer。
在什么情况下需要使用无锁编程？
需要使用无锁编程的场景包括信号处理、内核中断上下文和极端延迟要求的应用。
如何判断一个库是否真正是无锁的？
可以通过检查其是否满足progress guarantee、正确的内存顺序和是否处理ABA问题来判断一个库是否真正是无锁的。
