criticalSection(消息之间的独立性,保证状态的一致性)
来源:互联网 发布:阿里云 收入 编辑:程序博客网 时间:2024/05/10 19:26
criticalSection的解析:
调用queue获得临界区,维持单一代码运行 ,防伪并发
同一个 skynet 服务中的一条消息处理中,如果调用了一个阻塞 API ,那么它会被挂起。挂起过程中,这个服务可以响应其它消息。这很可能造成时序问题,要非常小心处理。
一旦你的消息处理过程有外部请求,那么先到的消息未必比后到的消息先处理完。且每个阻
塞调用之后,服务的内部状态都未必和调用前的一致(因为别的消息处理过程可能改变状态)。
skynet.queue 模块可以帮助你回避这些伪并发引起的复杂性。
local queue = require “skynet.queue”
获得的 queue 是一个函数,每次调用它都可以得到一个新的临界区。临界区可以保护一段代码不被同时运行。
local cs = queue() -- cs 是一个执行队列local CMD = {}function CMD.foobar() cs(func1) -- push func1 into critical sectionendfunction CMD.foo() cs(func2) -- push func2 into critical sectionend
比如你实现了这样一个消息分发器,支持 foobar 和 foo 两类消息。如果你使用 cs 这个 skynet.queue 创建出来的队列。那么在上面的处理流程中, func1 和 func2 这两个函数,都不会在执行过程中相互被打断。
如果你的服务收到多条 foobar 或 foo 消息,一定是处理完一条后,才处理下一条,即使 func1 或 func2 中有 skynet.call 这类的阻塞调用。一旦它们被挂起,新的消息到来后,新的处理流程会被排到 cs 队列尾,等待前面的流程执行完毕才会开始。
注:在 func1 函数内部再调用 cs 是合法的。即:
local function func2() -- step 3endlocal function func1() -- step 2 cs(func2) -- step 4endfunction CMD.foobar() -- step 1 cs(func1) -- push func1 into critical section -- step 5end
如果你这样写,每次收到 foobar 消息后,程序流程会按 step 1, step 2, step 3, step 4, step 5 这样执行,而不会死锁。
在这个过程中,如果 foobar 消息的处理流程被挂起,即使新的 foobar 消息到来,那么,新的消息会立刻执行 step 1 (因为没有被 cs 保护),然后等前一次的 step 4 结束后(step 5 不在 cs 保护中),开始新的 step 2 。
- criticalSection(消息之间的独立性,保证状态的一致性)
- STORM-消息一致性保证
- 数理逻辑:谓词逻辑(5)公理的一致性和独立性
- CriticalSection的使用
- ZooKeeper的一致性保证及Leader选举
- 冗余表如何保证数据的一致性
- 数据库的数据独立性
- 测试脚本的独立性
- Java的平台独立性
- Java的平台独立性
- Java的平台独立性
- 事件的独立性
- 随机变量的独立性
- 随机变量的独立性
- Mutex 和 CriticalSection 的 区别
- 错误的状况下,ceph IO 的一致性如何保证
- exp和expdp怎么保证数据的一致性?
- 编程幂等设计:数据最终一致性的保证
- Javascript学习之Map和Filter函数实现方法详解
- memset详解 设置无穷大INF
- linux部署java项目的war包
- Linux:查看目录下文件大小
- element ui里dialog关闭后清除验证条件
- criticalSection(消息之间的独立性,保证状态的一致性)
- 【jquery】凡客轮播图(仿)
- 三星C系列手机疑似要升级到安卓7.0,还另加手机数据恢复功能
- 【Java源码分析】为什么不可以在指定默认容量的ArrayList对象中插入元素
- js原生实现百叶窗上下滚动
- 支付宝接口的开发
- SpringMvc整合redis
- what fuck it is
- 逻辑思维