最近晓靖给 skynet 提了一个 pr 。 提之前我们讨论了好久，据说是因为查另外一个问题时改写了 skynet 的消息调度部分发现在某些情况下可以提高 CPU 的使用率。 之前 skynet 的消息调度采用的是基于 cas 的无锁结构。但本质上，并发队列这种数据结构，无论是
最近晓靖给 skynet 提了一个 pr 。
提之前我们讨论了好久，据说是因为查另外一个问题时改写了 skynet 的消息调度部分发现在某些情况下可以提高 CPU 的使用率。
之前 skynet 的消息调度采用的是基于 cas 的无锁结构。但本质上，并发队列这种数据结构，无论是采用 spin-lock 还是 cas 无锁结构，为了保证时序，进队列或出队列的部分都必须是依次进行的，也就是说，多核心无助于提高队列的性能。
使用无锁结构，无非是对发生冲突保有乐观态度，觉得大多数情况下冲突不会发生，一旦发生就采取重来一次的策略。
而使用 spin lock ，则是对冲突采取悲观策略，认为冲突经常发生，所以在操作共享字段时，锁住资源独享操作。
最终，都必须等前一件事情做完，才能接着做下一件事。
无锁结构的程序逻辑往往显得复杂，那么它的好处是什么呢？
无锁结构在乐观情况下，可以让处理过程尽量并行，只在可能发生冲突的那一刻才用系统的原子指令锁住一个字长的内存写入，然后立即放开。加锁和解锁是原子的，这样就可以回避死锁的问题。同时也不会因为 spin lock 锁住的指令过多（如果线程数多于核心数，就有可能在锁住的过程中发生线程挂起），而导致其它线程等待时间过长。
在 skynet 的核心消息队列调度模块中，无锁结构能获得的好处其实非常有限。为了简化代码，我们甚至不需要单独去锁队列的两端。因为在 skynet 的消息队列分两级。在运行过程中，如果此级队列有消息时，它根本不会进入全局主队列（用锁保证次序的那个队列）。
由于不再使用无锁队列，数据结构也可以大大简化。使用一个简单的单向链表就可以管理这个队列。之前为了解决队列长度问题，已经把次级队列设计成一个侵入式链表，这次要做的只是把那个数组部分去掉就可以了。
修改过后，一个明显的好处是突发的大量服务启动（往往是瞬间大量连接涌入造成的 agent 启动需求）变快了。 这解答了之前的一个疑问 。
原文地址：乐观锁和悲观锁, 感谢原作者分享。
下载本文