无锁和无等待并发

原文参考：http://rethinkdb.com/blog/lock-free-vs-wait-free-concurrency/，之前看ConcurrentLinkedQueue看到wait-free的东西，百度看到这篇文章，文章比较短，翻译下练手。

有2种类型的非阻塞线程同步算法：无锁和无等待，他们的含义经常被混淆。在无锁系统中，当任何一个特定的计算可能被阻塞一段时间的时候，所有其他的cpu可以继续其他计算。换个说法就是，无锁系统中一个线程被其他线程阻塞时，其他cpu可以继续没有拖延的做其他有用的工作(这里原文有个without stalls，感觉应该是without stalling，这样这句话才能说得通)。无锁算法增加了系统整体的吞吐量，与此同时可能会导致某一个特定事务的延迟。大多数多终端的数据库系统在一定程度上都是基于无锁算法。

相对而言，无等待算法确保所有cpu都在做有用的工作，没有任何一个计算会被其他计算阻塞。无等待算法能够确保在不牺牲特定事务延迟性的情况下比无锁算法有更高的吞吐量。他们也同样难以实现、测试、调试。Linux 内核的无锁page cache补丁就是无等待系统的一个例子。

在这样一个场景中，当一个系统需要处理几十个并发事务，对延迟性要求不高，这时在开发复杂性和高并发要求间无锁系统具有更好的平衡。无锁设计对于网站的数据库服务可能是一个好的选择。当一个事务阻塞时，在同一时刻总是有更多的事务在处理中，因此cpu永远不会空闲下来。可能的挑战是构造一个事务调度器，来维持一个好的平均延迟和令人满意的标准偏差（意思是即使有延迟，波动也不会太离谱）。

当一个系统拥有大概cpc内核个数的并发数或者实时性要求比较高时，开发者就需要来花费额外的时间构建无等待系统。在下面这些的情况下，阻塞一个事务时不能接受的：或者因为没有其他事务需要cpu处理，导致吞吐量降低，或者事务需要在指定时间内完成而不是一种概率性时间周期。核子反应堆控制软件就是无等待系统的一个很好的例子。

RethinkDB是一个无锁系统。一台机子有N个cpu内核，在大多数工作负载中，在大概有N*4的并发事务时，我们可以保证没有内核会空闲，并且io管道容量也不会被浪费。举个栗子，在一个8核的系统中，如果RethinkDB处理大概32个或者更多个并发事务，硬件就不会有一丝一毫的空闲。如果少于32个事务，你可能就不需要那么核数。（当然如果你仅有32个并发事务，你根本不需要8核的机器。）

个人理解：

lock-free应该是有race的情况下，同一个时刻，只会有一个成功，其他不成功的就需要不断尝试(例如cas操作)导致大家都堵在这里，而wait-free有race，同一时刻，即使只有一个成功了，但是其他失败的代码也能继续运行，不会挂死在那，然后通过其他方法(例如ConcurrentLinkedQueue，offer的时候即使cas失败了也无所谓，再去for循环就是，不会说我cas失败，我就要拼命的继续cas)。

晚上生产代码发布，第一次翻译，明天校对下！

参考：

http://rethinkdb.com/blog/lock-free-vs-wait-free-concurrency/ 原文地址

2篇并发网无锁的文章，也是翻译人家的，多看看也许会明白，其实我也只看懂了一些
http://ifeve.com/lock-free-and-wait-free/ 
http://ifeve.com/why-is-wait-free-so-important/