锁实现分析:从glibc到futex(一)
之前在理解条件变量时在futex上误入歧途,导致犯下死锁的错误,并且写下了错误的博文,见浅析条件变量
所以打算重新理解一下futex
虽然初衷是futex,但是由于futex最初是为了优化锁的性能而提出,因此深入理解futex实际上是对锁概念的深入了理解
因此本篇的大纲
源码分析从c++的mutex开始,然后是glibc的nptl库pthread_mutex,接着是linux内核的futex实现
我对内存屏障以及C++11引入的memory order一直处于一知半解的状态
知道有这么个东西,知道一部分原理,不知道什么场合去用它,一直以来我的多线程工具库里面只有锁,条件变量和原子变量三板斧,错过了很多更细粒度的优化机会。
在ChatGPT的帮助下,终于从头到尾理解了它的底层原理和应用场景
本文属于拾人牙慧的总结,将看到的一些资料整理出来,本文的大纲如下:
缓存一致性
从cpu缓存开始,引出多核cpu的缓存一致性(Cache Coherence)问题
为了解决这个问题,发明了MESI协议,但是这个协议性能还不够好,因此引入了Store Buffer和Invalidate Queue来提高性能
内存一致性
Store Buffer,Invalidate Queue再加上编译器指令乱序和cpu指令乱序,导致了内存一致性(Memory Consistency)无法得到满足
使用各种内存屏障来解决这些问题
C++的memory order
为了简化和细化内存屏障,C++11引入了memory order
由于公司使用的taf框架是和开源的tars框架一脉相承,虽然经过几年的改造,几乎已经面目全非了,但是主体结构上相差不大
因此从tars框架的最初版本的源码分析上就可以理解整个核心链路了
本篇会分析开源的tars1.0版本和tars3.0版本,并探索3.0版本的优化原因,最后对他们的性能做一些比较
计划中还有一篇公司taf框架的分析,很有趣的是它的发展方向和tars3.0不太一致,因此可以对其性能和tars性能也做一番比较,遗憾的是出于保密需要,无法将其post在我的博客上了
由于redis和leveldb的兴起,跳表走入了大众的实现
相对红黑树而言,跳表非常容易理解,使其成为了红黑树的常见替代
刚好我在理解2-3-4树的时候写了红黑树,顺便写一个跳表来pk一下性能
结果是我万万没想到的:
在单线程下,跳表的性能几乎全方位被红黑树碾压
之前写过一篇c++ 分析 gperftools 总结
对普通的性能优化来说,gperftools已经足够了
但是如果要深入优化,还是需要借助linux内置的perf工具
这个工具的功能包括但不限于:
hook是一个非常有用的黑魔法
协程基于它的最大应用之一
我总结了一下hook的原理,和我遇到的hook场景
我第一次看到hook这个词是在破解论坛上,大致意思是将指定函数替换成自己的,然后再去执行这个指定函数