用std::shared_mutex做读写分离,20个读线程把写线程饿了3秒——读了pthread_rwlock源码才找到真正的原因

张开发
2026/4/11 15:26:20 15 分钟阅读

分享文章

用std::shared_mutex做读写分离,20个读线程把写线程饿了3秒——读了pthread_rwlock源码才找到真正的原因
20个线程并发读,1个线程写。写线程等了3176毫秒才拿到锁。不是死锁。不是bug。是std::shared_mutex的默认行为。大多数 C++ 程序员第一次用读写锁的时候,心里的预期模型是这样的:读者拿共享锁、写者拿独占锁,写者来了读者就等一下,读者来了写者也等一下,大家排队轮流来。这个预期在某些平台上是成立的——但在 Linux 上用 GCC 编译的std::shared_mutex,默认行为和这个预期相去甚远。写者来了,读者不但不等,还能继续插队进去拿锁。这篇从一个压测翻车现场出发,一路追到 libstdc++ 的shared_mutex实现、glibc NPTL 的pthread_rwlock_common.c源码,把读写锁的读优先策略是怎么让写线程活活饿死的,一行一行拆给你看。读完你会拿到三样东西:饥饿复现的完整压测代码、glibc 源码中读优先判断的关键路径、以及一份"什么场景该用什么锁"的工程决策清单。压测现场:写线程等了3秒先看代码。这是一个标准的读多写少场景:一个配置中心,20个线程并发读配置,1个线程定期更新配置。全局变量和读线程的逻辑很直接:#include/

更多文章