Lock-free VS wait-free
来源:互联网 发布:开源地面站 安卓源码 编辑:程序博客网 时间:2024/05/30 05:19
个人的一个理解是这样的:无锁系统是相对于多个线程来说的,当其中一个线程阻塞的时候,其他线程可以继续运行,相互不影响。无等待系统更像是针对一个线程来说的,该线程在运行过程中不会被任何运算所阻塞。有两种非阻塞线程同步算法,即无锁和无等待,这两种算法经常会产生混淆。
在无锁系统中,当任何特定的运算被阻塞的时候,所有CPU可以继续处理其他的运算。换种方式说,在无锁系统中,当给定线程被其他线程阻塞的时候,所有CPU可以不停的继续处理其他工作。无锁算法大大增加系统整体的吞吐量,因为它只偶尔会增加一定的交易延迟。大部分高端数据库系统是基于无锁算法而构造的,以满足不同级别。
相反,无等待算法保证了所有CPU在连续处理有效工作的时候,没有运算会被其他运算所阻塞。相比于无锁算法,无等待算法有更强的保证,并且不会以交易延迟为代价,来保证高吞吐量。当然,相比之下这种算法也更难实现,测试和debug。Linux kernel的无锁页面缓存就是无等待系统的一个典型案例。
在某些情况下,例如系统在处理一些并发交易并且有一些轻微的延迟请求,无锁系统是在开发难度和高并发请求的一个好的折中选择。网站的数据库服务器就是一个很好的无锁设计的例子。当任何请求交易被阻塞,同时总是有更多的交易在被处理,因此CPU永远不会空闲。难点就是要建立一个交易调度器,来维护一个比较好的平均延迟和一定的误差。
在某些场景下,系统拥有和cpu核心数量相似的并发交易,或者很准确的实时请求,开发者就需要花费更多的时间去构建无等待系统了。在这种案例中,例如:阻断单一交易是不行的,因为cpu没有其他交易可以操作,最小的吞吐量,或指定的交易需要在一个非概率化的时间段内完成。核反应控制软件就是一个无等待系统的绝好案例。
RethinkDB是一个无锁系统。在一台具备N个CPU核心的机器上,在大量正常负载的情况下,我们可以保证没有任何核心会处于空闲状态,只要有大约N×4的并发交易,则可以保证没有io管道容量被浪费。例如,一个8核心的系统,如果RethinkDB正在处理大概32个或更多的并发交易时,没有任何硬件会处于空闲。如果通常只有少于32笔的并发交易,那么有些核心也许是浪费了。(当然如果你仅仅有32笔并发数量的话,也不需要一个8核的机器)
- Lock-free VS wait-free
- Lock-free vs. wait-free concurrency
- lock-free&wait-free
- wait-free 和 lock-free 资料收集
- lock-free/wait-free算法以及ABA问题
- Lock-Free
- Lock-Free
- Lock-free论文集
- lock free 编程
- Lock-Free Algorithms
- linux内核 lock free
- Lock Free Stack
- Lock-Free的理解
- Lock-Free Data Structures
- lock free 之 stack
- 《Implementing Lock-Free Queues》
- Lock-Free Data Structures
- lock free编程思想
- Java中对日期的操作(获取、比较、排序、间隔)
- 管理媒体播放(2)管理媒体的聚焦
- BEGIN expected in dialog error
- 关于JEECG数据导入的改进完善
- 文本编辑器
- Lock-free VS wait-free
- 数据结构(一):顺序表
- Android Volley框架的几种post提交请求方式
- SWFUpload
- showModalDialog在chrome下
- 如何销毁Activity,和如何一次销毁多个activity
- umeng用户反馈报错NoClassDefFoundError
- iOS 键盘类型设置
- maven 搭建私服