Lock-free VS wait-free

转载自并发编程网

有两种非阻塞线程同步算法，即无锁和无等待，这两种算法经常会产生混淆。

在无锁系统中，当任何特定的运算被阻塞的时候，所有CPU可以继续处理其他的运算。换种方式说，在无锁系统中，当给定线程被其他线程阻塞的时候，所有CPU可以不停的继续处理其他工作。无锁算法大大增加系统整体的吞吐量，因为它只偶尔会增加一定的交易延迟。大部分高端数据库系统是基于无锁算法而构造的，以满足不同级别。

相反，无等待算法保证了所有CPU在连续处理有效工作的时候，没有运算会被其他运算所阻塞。相比于无锁算法，无等待算法有更强的保证，并且不会以交易延迟为代价，来保证高吞吐量。当然，相比之下这种算法也更难实现，测试和debug。Linux kernel的无锁页面缓存就是无等待系统的一个典型案例。

在某些情况下，例如系统在处理一些并发交易并且有一些轻微的延迟请求，无锁系统是在开发难度和高并发请求的一个好的折中选择。网站的数据库服务器就是一个很好的无锁设计的例子。当任何请求交易被阻塞，同时总是有更多的交易在被处理，因此CPU永远不会空闲。难点就是要建立一个交易调度器，来维护一个比较好的平均延迟和一定的误差。

在某些场景下，系统拥有和cpu核心数量相似的并发交易，或者很准确的实时请求，开发者就需要花费更多的时间去构建无等待系统了。在这种案例中，例如：阻断单一交易是不行的，因为cpu没有其他交易可以操作，最小的吞吐量，或指定的交易需要在一个非概率化的时间段内完成。核反应控制软件就是一个无等待系统的绝好案例。

RethinkDB是一个无锁系统。在一台具备N个CPU核心的机器上，在大量正常负载的情况下，我们可以保证没有任何核心会处于空闲状态，只要有大约N×4的并发交易，则可以保证没有io管道容量被浪费。例如，一个8核心的系统，如果RethinkDB正在处理大概32个或更多的并发交易时，没有任何硬件会处于空闲。如果通常只有少于32笔的并发交易，那么有些核心也许是浪费了。（当然如果你仅仅有32笔并发数量的话，也不需要一个8核的机器）

个人的一个理解是这样的：无锁系统是相对于多个线程来说的，当其中一个线程阻塞的时候，其他线程可以继续运行，相互不影响。无等待系统更像是针对一个线程来说的，该线程在运行过程中不会被任何运算所阻塞。