《Bistro: Scheduling Data-Parallel Jobs Against Live Production Systems》
facebook2015年论文，用于解决离在线混部时，约束离线任务运行在指定资源范围的问题
提出了一种基于树模型的资源调度问题
例如叶子节点是数据库卷，上面的父节点是主机，机架等等
在任务退出时，对影响到的叶子节点以及父节点（直到根节点）进行调度，来避免全部资源池的调度太过耗费性能
Bistro在架构上允许对树的独立资源的根节点，哈希或者按位置进行分区，从而进行并行调度和分布式调度
最近大概间隔1个月，我在使用定时任务类时遇到了两次析构过程中的 bug
这两个 bug 出现在我用别人写的定时任务类时，这两个bug的区别是一个是组合使用的，另一个是继承使用的
由于coredump的堆栈都不在正常的位置，因此这两个bug都花费了我平均一整天的大量时间去定位
另外有个基于协程的定时任务类，这个类不仅只是使用，甚至都是我实现的，尽管 bug 还未发生，我仔细看了下居然也存在类似的问题
因此，我觉得我有必要总结这个问题，避免再次在相同的问题上耗费太多时间，毕竟多线程（协程）问题的定位非常困难
上一篇对glibc和futex进行了源码分析，是我对具体实现的梳理，没有总结性的内容，可以略过不看直接看这一篇总结
本篇总结尝试深入一些，继续挖掘锁这个概念
分析内核在实现锁的过程中是如何解决无效唤醒问题的
为了解决无效唤醒问题，纯用户态的互斥锁性能不够好；纯内核态又在非竞争的条件时需要陷入内核，从而诞生了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
在C++中，有一些不太常见的小技巧，甚至有些能够被称之为黑魔法
当你的代码需要同时服务某个库的新旧版本，希望调用新增接口，又不希望这个库的旧版本因为没有这个接口报错
对C++的基础库开发者来说，这是很常见的需求，因为你的库依赖的底层库，不一定可以强行指定版本，那么此时这个兼容性神器就可以出场了
这是一个简单的例子