拯救多线程混乱的 pelagia

全文地址: gameinstitute.qq.com/community/detail/133448

导致多线程混乱的依赖和死锁问题。

在介绍各种多线程开发工具前我先要介绍下多线程下最大的二个问题。

第一个问题就是任务执行的依赖关系。在不同线程间执行的任务代码会有先后次序的需求。但因为多线程的特性会导致这些代码被同时执行。那么需要一种方法来控制多线程间代码的依赖关系。违反这种依赖关系可能会导致数据的丢失。执行过程的严重错误。甚至崩溃，死机。

第二个问题就是死锁。在多线程执行过程中，多个线程会访问同一个数据。如果其中一个线程锁住了一个数据，然后请求另一个数据的锁。而其他线程刚好锁住了他请求中的数据，并也刚好请求他拥有的数据。就会导致两个线程互相等待系统卡死的问题。

为什么多线程下这两个问题是核心问题？因为这两个问题的出现与多线程软件规模成正比，也就是说随着多线程软件规模的增加，这两个问题出现的概率也在增加。他们像达克摩斯之剑一样悬挂在任何多线程项目的上空。

pelagia

是开源项目其地址在 github.com/surparallel/pelagia

pelagia 是由 surparallel open source 推出的开源项目，是唯一同时解决依赖和死锁的多线程工具。在前面我简单的介绍了多线程工具的现状。我们知道依赖和死锁是多线程开发中必须要解决的两个问题。并不是简单的因为依赖和死锁会有概率的出现在多线程项目中。而是因为在多线程项目中存在指数规模效应的问题。

所谓指数规模效应是指假设一个项目有两个线程，如果你新添加一个线程，那么两个线程间发生依赖和死锁，就有 3 的 2 次方即 9 种可能。如果有 99 个线程，你同样是新添加一个线程，那么发生依赖和死锁的可能就变成了 100 的 2 次方种可能。也就是说可能发生依赖和死锁的状况，随着开发任务的增加成指数级别的增加。

这样就导致每开发一个新的线程任务就要和其余的线程任务做仔细的检查。检查是否可能出现依赖和死锁。而这种检查的规模也是程指数增加的。这样就导致我们开发的多线程项目很快就会达到团队所能承受的极限。

因为指数规模效应的存在就必然会有祖传代码拍死老师傅。为了避免老师傅们被祖传代码拍死。pelagia 结合消息通信和数据分区两个技术，同时解决依赖和死锁问题，彻底拯救了老师傅。

pelagia 目前处于准完成阶段。大部分功能已经开发完毕。包括消息通信的统计系统，支持多线程的日志系统，多线程数据分区的存储系统。其硬盘储存系统性能略快于 redis 。

sgissb1

2020-07-29 22:37:23 +08:00

死锁的出现，一般有三种：
1，疏忽大意
2，根本不懂多线程是什么
3，不懂最基本的代码设计和模块排列，就装架构师，模仿设计模式搞事情，或者创造新的设计模式。

一般第一种也很多，但对于线程操作熟练工和代码模块设计和排列的熟练工来说，稍微好一点的代码习惯这个问题就会少很多。

现在不管 c 还是 c++程序员，第二种和第三种居多。因为 c/c++和 java 类开发工具的线程调度模型稍有区别，主要是没有类似 gc 等会打断线程的开发语言特性的软 /硬中断。

所以其线程相当接近硬件调度模型和操作系统调度模型的情况。做非嵌入式的，操作系统和硬件都稍微了解一些，在平时养成好一点的代码习惯，加上不要没事瞎装架构师，算法工程师，操练个 2-3 年的同时渐渐从上到下（指底层调度）的做个了解，基本没有太大问题。

工程问题在于取舍，而取舍在于经验，正确的经验积累在于正确正确的基础知识和踏实。可惜现在程序员和韭菜一样，一茬一茬的割，加上“我的代码拯救世界”的心态流行。本来很不算太难的事情，其实很难。