boost是否像Linux一样提供读写自旋锁机制？

用户态 spinlock 这个东西，其实没多大用。（其实在内核态用的地方也很少，基本上依赖 scheduler 的代码都不能用。）

如果你看过 Linux kernel 代码，你会知道在 disable SMP 的时候，spinlock 是一个空函数。在 Linux kernel 里，spinlock 仅仅是一个在多核之间做同步的机制。这个机制用在普通的线程模型上意义不大。

为什么说意义不大呢？你看用 spinlock 的初衷是什么？是为了让 waiting thread 不被挂起，不用产生进程 suspend-reschedule 的开销。但是你要让 waiting thread 等待的尽量短，还要有一个要求，就是 lock-owning thread 得赶紧把事情干完。那你怎么保证 lock-owning thread 赶紧完事呢？你得保证 waiting thread 和 lock-owner 运行在不同 CPU 上，而且 lock-owner 最好能 disable interrupt 防止自己被 preemptively suspend。否则的话，不光还要有 thread switch，而且 lock-owner 还可能去空等待 waiting thread，因为后者在 busy-waiting 而并非挂起。所以你看，这个条件只有在 kernel 里操作多核的特殊代码才能满足。在用户空间的线程是不知道自己是不是运行在同一个核上的。

所以说 spinlock 在用户空间有可能反而比 mutex 要慢。这个东西实在是鸡肋。只要你已经把自己的代码托付给了 scheduler，mutex 是目前最好的同步模型。（当然 atomic 和 memory barrier 也是，但是它们都不能构建任意长的 critical region。）

而且 disk I/O 本来就会 voluntarily relinquish CPU。这种 lock-owner 为什么还要用 spin lock 我就看不懂了。