1. 项目概述为什么我们需要原子同步在Linux系统编程尤其是多线程、多进程并发编程的世界里有一个词让无数开发者又爱又恨那就是“竞态条件”。想象一下你和你的同事在同一个共享的Excel表格里同时修改一个单元格的数值如果没有任何协调机制最终这个单元格的值会变成谁修改的结果答案是不确定。这会导致数据错乱、程序崩溃甚至更隐蔽的逻辑错误。在计算机里当多个执行流线程或进程同时访问和修改同一块内存数据时就会发生同样的问题。为了解决这个问题我们引入了“同步”机制比如互斥锁、信号量、读写锁等。它们像是会议室的门一次只允许一个人进去操作共享数据。但锁的代价是昂贵的它涉及到操作系统的介入、线程的挂起与唤醒这在频繁访问的“热点”数据上会成为性能瓶颈。于是硬件和编译器为我们提供了另一条路原子操作。原子操作的核心思想是“要么全做要么不做”一个操作在执行过程中不会被任何其他操作打断。__sync_val_compare_and_swap简称CAS就是这类原子操作中的“瑞士军刀”它是实现无锁数据结构、高性能计数器、自旋锁等并发原语的基石。今天我们就来彻底拆解这个函数从原理到实战让你不仅会用更能理解其背后的设计哲学和避坑要点。2. 核心原理CAS到底在做什么__sync_val_compare_and_swap是GCC编译器提供的一系列内置原子操作函数__sync_*中的一个。这些函数在x86、ARM等主流平台上会被编译器翻译成对应的CPU原子指令例如x86的cmpxchg。它的函数原型通常如下type __sync_val_compare_and_swap (type *ptr, type oldval, type newval);type *ptr: 指向需要修改的目标内存地址的指针。type oldval: 我们“预期”目标内存地址当前存储的值。type newval: 我们希望“设置”到目标内存地址的新值。它的执行逻辑是一个不可分割的原子操作读取指针ptr指向的当前值。将这个当前值与传入的oldval进行比较。如果相等说明从我们“预期”到现在没有其他线程修改过这个值。那么将newval写入ptr指向的位置。函数返回这个位置修改之前的值也就是oldval。如果不相等说明在我们读取预期值之后、执行CAS操作之前已经有其他线程修改了ptr指向的值。那么什么也不做不进行写入。函数返回ptr指向的位置当前的实际值。注意整个“读取-比较-交换”的过程是一条CPU指令完成的在多核系统中这条指令会锁住内存总线或使用缓存一致性协议如MESI来保证其原子性确保在执行期间其他核心无法访问这块内存。一个生活化的类比这就像你去超市寄存柜存包。你拿到一张纸条预期值oldval上面写着“A05柜空闲”。你走到A05柜前目标地址ptr执行CAS操作看一眼柜门显示的状态当前值如果显示“空闲”等于oldval你立刻刷卡把它改成“占用”并存入你的包写入newval操作成功。如果你看到显示“占用”不等于oldval说明在你拿到纸条走到柜子前已经有人用了你的操作失败需要重新去取一张新纸条获取新的预期值。这个“查看-比较-交换”的原子性是CAS实现无锁同步的关键。它避免了使用锁而是采用了一种“乐观”的并发策略我先假设没人跟我抢直接去改如果发现有人改过了比较失败那我就重试。这在冲突不频繁的场景下性能远高于悲观锁。3. 函数详解与参数剖析理解了核心原理我们再来深入看看这个函数的细节和变体。__sync_val_compare_and_swap支持多种整数类型GCC会根据type的类型选择对应的机器指令。支持的type:所有整数类型int,unsigned int,long,unsigned long,long long,unsigned long long。指针类型void*或任何其他指针类型。当用于指针时它比较和交换的是指针值内存地址。返回值详解 这是最容易混淆的地方。函数总是返回ptr指向的内存在操作发生之前的值。操作成功时因为操作前值等于oldval所以返回值等于oldval。操作失败时因为操作前值不等于oldval所以返回值是那个不等于oldval的当前值。因此判断操作是否成功的唯一标准是比较返回值是否等于你传入的oldval。int old *ptr; // 先获取预期值 int ret __sync_val_compare_and_swap(ptr, old, new); if (ret old) { // 成功从获取old到CAS完成没有其他线程干扰。 } else { // 失败在此期间ptr已被修改ret就是当前的新值。 // 通常需要用ret作为新的oldval进行重试。 }函数家族变体 GCC的__sync_*系列还有其他几个常用的CAS相关函数需要区分__sync_bool_compare_and_swap(ptr, oldval, newval):这是另一个常用变体。它只返回一个bool值成功返回true失败返回false。它不返回旧值。当你只关心操作是否成功而不关心当前值是什么时用这个更直观。if (__sync_bool_compare_and_swap(counter, 10, 11)) { printf(“成功将10改为11\n”); }其他原子操作如__sync_fetch_and_add原子加、__sync_lock_test_and_set原子交换等它们都是基于类似的硬件原语但封装了特定语义。内存序问题 这是一个高级话题但必须提及。__sync_*系列函数提供的是完全内存序。这意味着在原子操作之前的所有内存读写Load/Store都不会被重排到该原子操作之后。在原子操作之后的所有内存读写都不会被重排到该原子操作之前。该原子操作本身对系统中所有其他线程或核心是立即可见的。 对于大多数应用这已经足够。但在极致性能优化的无锁数据结构中可能会用到更精细的内存序控制如__atomic_*系列函数提供的memory_order_relaxed等这超出了本篇基础范围但你需要知道__sync_*是“最强”的一致性保证。4. 实战演练从简单计数器到无锁栈理论说再多不如一行代码。我们通过几个经典案例看看CAS如何大显身手。4.1 案例一实现一个线程安全的原子计数器这是CAS最直接的应用。我们不用锁而是用CAS循环来保证计数的正确性。#include stdio.h #include pthread.h #include stdint.h // 共享计数器 int64_t counter 0; void* increment(void* arg) { int loops *(int*)arg; for (int i 0; i loops; i) { int64_t old_val, new_val; do { old_val counter; // 1. 读取当前值作为预期值 new_val old_val 1; // 2. 计算新值 // 3. 尝试CAS如果counter还是old_val就设为new_val // 返回值如果等于old_val说明成功跳出循环。 // 如果不等于说明被其他线程改了用返回值更新old_val重试。 } while (__sync_val_compare_and_swap(counter, old_val, new_val) ! old_val); } return NULL; } int main() { pthread_t t1, t2; int loops_per_thread 1000000; pthread_create(t1, NULL, increment, loops_per_thread); pthread_create(t2, NULL, increment, loops_per_thread); pthread_join(t1, NULL); pthread_join(t2, NULL); printf(“Final counter value: %ld\n”, counter); // 正确输出 2000000 printf(“Expected value: %d\n”, 2 * loops_per_thread); return 0; }实操要点与心得循环重试是关键CAS可能失败所以必须放在一个循环里。这个模式叫“CAS Loop”或“乐观锁循环”。局部变量存储一定要把counter读出来存到局部变量old_val再用于计算和比较。如果直接写成while(__sync_val_compare_and_swap(counter, counter, counter1) ! counter)由于参数求值顺序和counter的多次读取会产生严重的竞态条件逻辑完全错误。性能考量在高并发、高冲突的场景下很多线程频繁修改同一个计数器CAS循环可能导致大量的重试“忙等待”消耗CPU。这时传统的锁可能因为会让线程休眠而效率更高。CAS适用于低冲突场景。4.2 案例二构建一个简单的无锁栈Lock-Free Stack无锁栈是展示CAS威力的经典数据结构。栈的核心操作是push入栈和pop出栈我们需要原子地更新栈顶指针。#include stdlib.h #include stdio.h // 栈节点定义 typedef struct node_t { int value; struct node_t *next; } node_t; // 栈顶指针哨兵 node_t *top NULL; // 无锁Push操作 void lock_free_push(int value) { node_t *new_node (node_t*)malloc(sizeof(node_t)); if (!new_node) return; new_node-value value; node_t *old_top; do { old_top top; // 获取当前栈顶 new_node-next old_top; // 新节点指向旧栈顶 // 尝试将栈顶从old_top原子地更新为new_node } while (!__sync_bool_compare_and_swap(top, old_top, new_node)); } // 无锁Pop操作 int lock_free_pop() { node_t *old_top, *new_top; do { old_top top; if (old_top NULL) { // 栈为空 return -1; // 或者用其他方式表示空栈 } new_top old_top-next; // 新的栈顶应该是旧栈顶的下一个节点 // 尝试将栈顶从old_top原子地更新为new_top } while (!__sync_bool_compare_and_swap(top, old_top, new_top)); int value old_top-value; free(old_top); // 注意这里存在“ABA问题”下文详述 return value; }代码解析与陷阱Push操作创建新节点让其next指向当前栈顶然后尝试用CAS把栈顶指针top从old_top换成new_node。如果期间有其他线程修改了栈顶CAS失败循环重试。Pop操作获取当前栈顶如果非空则计划将栈顶设置为old_top-next。同样用CAS原子更新。成功后取出值并释放旧节点内存。致命的“ABA问题”这是无锁数据结构设计中最著名的陷阱。考虑以下时序线程A执行pop读到栈顶为Xold_top X并计算出new_top X-next。在A执行CAS之前线程B执行了pop成功弹出X然后push了一个新节点Y紧接着又push了一个节点巧合的是这个新节点分配的内存地址恰好是刚才释放的X的地址内存重用很常见此时栈顶又变成了X内容可能不同。线程A现在执行CAS它比较top和old_top都是X发现相等于是成功将top设置为X-next。结果线程B新加入的、本应在栈上的节点X被错误地移除了可能导致数据丢失或程序崩溃。这就是“ABA”——值从A变成B又变回A但上下文已变简单的值比较无法察觉。4.3 解决ABA问题使用带标签的指针解决ABA问题的常见方法是“标签法”。我们不仅仅比较指针值还附加一个随着每次修改而递增的版本号或标签。#include stdint.h // 假设指针是64位系统我们利用高16位作为标签(tag)低48位作为地址现代x64 CPU实际只用48位寻址 typedef union pointer_tag_t { struct { uintptr_t ptr : 48; // 实际指针地址 uintptr_t tag : 16; // 标签 }; uintptr_t uval; // 整个用于CAS操作的值 } pointer_tag_t; // 栈顶现在是一个复合值 pointer_tag_t top_tag { .ptr 0, .tag 0 }; void lock_free_push_tagged(int value) { node_t *new_node (node_t*)malloc(sizeof(node_t)); new_node-value value; pointer_tag_t old_top, new_top; do { old_top top_tag; // 读取当前复合值 new_node-next (node_t*)old_top.ptr; // 新节点指向旧地址 new_top.ptr (uintptr_t)new_node; new_top.tag old_top.tag 1; // 标签递增 } while (!__sync_bool_compare_and_swap(top_tag.uval, old_top.uval, new_top.uval)); } int lock_free_pop_tagged() { pointer_tag_t old_top, new_top; node_t *old_node; do { old_top top_tag; old_node (node_t*)old_top.ptr; if (old_node NULL) return -1; new_top.ptr (uintptr_t)old_node-next; new_top.tag old_top.tag 1; // 弹出也要增加标签 } while (!__sync_bool_compare_and_swap(top_tag.uval, old_top.uval, new_top.uval)); int value old_node-value; free(old_node); return value; }原理每次修改栈顶无论是push还是pop我们都将标签tag加1。即使地址ptr被重用从A到B再到A标签也早已不同例如从tag1变成tag2。CAS操作比较的是整个uval包含标签因此能有效检测出ABA情况。这是工业级无锁数据结构库如libcds,Folly中的标准做法。5. 常见问题、性能考量与避坑指南在实际项目中使用CAS你会遇到各种坑。下面是我踩过的一些雷以及对应的解决方案。5.1 典型问题排查表问题现象可能原因解决方案与排查思路CAS操作始终失败陷入无限循环1.oldval获取错误不是最新的值。2. 在计算newval的过程中共享状态已被多次修改导致oldval永远“过时”。3. 指针或内存对齐问题某些架构要求原子操作地址对齐。1. 检查oldval是否是从目标指针ptr中最新读取的。2. 考虑冲突是否太激烈可能需要退避策略或改用锁。3. 确保ptr指向的内存地址是自然对齐的如4字节对齐对于int。使用malloc或栈变量通常没问题。程序出现偶发性数据损坏或崩溃1.ABA问题在无锁链表中最常见。2. 内存访问违规在CAS成功后访问了已被其他线程释放的内存如pop后访问已free的节点。3. 非原子操作的组合不是线程安全的。1. 引入标签指针或版本号解决ABA问题。2. 使用安全的内存回收方案如风险指针、引用计数、epoch-based reclamation。3. 确保对共享数据的任何非原子修改都在同步原语保护下或本身就是原子的。性能不如预期甚至比互斥锁还差1.高冲突多个线程频繁CAS同一内存位置导致大量缓存行在多核间无效化Cache Line Bouncing和CAS重试。2. 不必要地使用了完全内存序限制了编译器和CPU的优化。1. 尝试减少争用使用线程局部存储、分片计数器如每个线程一个计数器最后汇总。2. 对于性能极度敏感的场景研究并使用C11__atomic_*系列函数选择更宽松的内存序如memory_order_acq_rel。在ARM等弱内存序架构上行为异常__sync_*系列提供强内存序通常没问题。但如果混用其他非原子操作或自己用汇编实现可能因内存序问题导致乱序执行。坚持使用编译器内置原子函数避免手写汇编。理解并正确设置内存屏障Memory Barrier。5.2 性能优化心得减少争用是王道CAS的性能瓶颈在于“争用”。如果一个全局计数器被所有线程疯狂修改性能会很差。一个优化方法是使用“分片计数器”创建与CPU核心数相等的计数器数组每个线程根据自己的ID修改对应的槽位。最终需要结果时再求和。这牺牲了一些实时一致性但大幅减少了缓存行竞争。退避策略在CAS失败后不要立即重试可以加入短暂的等待如pause指令、sched_yield()或指数退避让持有资源的线程有机会完成操作减少无用的CPU循环。选择合适的原子原语GCC的__sync_*是旧接口C11标准引入了stdatomic.h和__atomic_*内置函数。后者功能更强大、更标准并且允许指定内存序。在新项目中建议优先使用C11原子操作。#include stdatomic.h _Atomic int atomic_counter 0; int old atomic_load(atomic_counter); while (!atomic_compare_exchange_weak(atomic_counter, old, old 1)) { // CAS失败old已被更新为当前值继续循环 }5.3 一个真实的避坑案例自旋锁的实现与陷阱我们用CAS实现一个简单的自旋锁Spinlock并看看其中的坑。typedef struct spinlock_t { int lock; // 0表示未上锁1表示已上锁 } spinlock_t; void spin_lock(spinlock_t *s) { while (__sync_lock_test_and_set(s-lock, 1)) { // 忙等待 // 这里可以加入 __asm__ volatile(“pause” : : : “memory”); (x86) 以减少功耗和总线压力 } } void spin_unlock(spinlock_t *s) { __sync_lock_release(s-lock); }这里用了__sync_lock_test_and_set它原子地将值设置为1并返回旧值常用于实现锁。看起来很简单对吧坑在哪里在于内存序和编译器优化。__sync_lock_test_and_set和__sync_lock_release配对使用它们提供的是“获取-释放”语义足以保证锁内的临界区不会与锁外的操作乱序。但如果你在临界区内调用了非内联函数或者访问了通过指针传递的共享数据编译器可能会做一些你意想不到的优化。更稳健的做法是使用C11原子操作并明确内存序#include stdatomic.h typedef struct spinlock_t { atomic_flag flag ATOMIC_FLAG_INIT; } spinlock_t; void spin_lock(spinlock_t *s) { while (atomic_flag_test_and_set_explicit(s-flag, memory_order_acquire)) { // 忙等待可加入pause } } void spin_unlock(spinlock_t *s) { atomic_flag_clear_explicit(s-flag, memory_order_release); }memory_order_acquire确保锁之后的读操作不会重排到锁之前memory_order_release确保锁之前的写操作不会重排到锁之后。这为临界区提供了正确的保护。6. 进阶在现代C/C中替代方案虽然__sync_val_compare_and_swap依然有效且广泛使用但现代C/C有了更标准、更强大的选择。C11标准使用stdatomic.h头文件。它定义了_Atomic类型修饰符和一系列原子操作函数如atomic_compare_exchange_strong/weak。这是可移植性最好的方式。C11及以上使用atomic头文件。提供了std::atomicT模板类语法更自然功能最全支持各种内存序、原子算术运算等。#include atomic std::atomicint counter{0}; int old counter.load(); while (!counter.compare_exchange_weak(old, old 1)) { // CAS失败old已被更新 }编译器内置函数GCC和Clang都推荐使用__atomic_*系列内置函数如__atomic_compare_exchange_n作为__sync_*的升级版它们支持更精细的内存序控制。迁移建议在新项目中尤其是C项目强烈建议直接使用std::atomic。对于C项目使用C11的_Atomic。只有在维护旧代码或需要与特定旧编译器兼容时才继续使用__sync_*。原子操作特别是CAS是深入理解并发编程的钥匙。它让你摆脱对操作系统锁的完全依赖在特定场景下写出性能极致且正确的代码。但记住这是一把双刃剑无锁编程的复杂度远高于基于锁的编程。从简单的计数器开始练习理解其原理和ABA等经典问题再逐步挑战更复杂的无锁数据结构。在真正需要性能瓶颈的地方才考虑使用它并且一定要进行充分且严苛的并发测试。