并发编程的模型

并发编程的模型

 

并发是多核编程中非常困难的部分，主要原因是多个CPU，但是共享一个内存，所以必须有一套机制保证这些CPU不会冲突。

 

理论上一个应用程序绑定一个CPU，然后从头执行到尾是最高效的方式，然而实际中的应用，总是会相互依赖，或者依赖某个低速的IO操作，这时候这些应用就会等待。等待的时候能高效的将CPU出让给别人是很重要的。

 

为了并发且保护共享的数据结构，很多的方式被发明出来，例如锁，互斥变量，信号量等。这些方式解决的是可以同时执行的多个程序直接的协调问题。这些协调工具侧重点各不同，而且出现冲突的时候的处理也不同，稍不注意就可能出现死锁，或者效率低下的问题。可以说并发编程为啥困难，主要就是如何利用这些工具保证程序运行的正确性和性能非常的复杂。

 

抽象来看，程序可以分割成多个原子部分，每个原子部分不会等待别人，从而能够高效的利用CPU，而这些部分之间，是互相依赖的。这个依赖就两种：

1. 等待访问公共的内存；
2. 等待访问外部的慢IO。

 

当处理冲突的时候，系统提供的常用方式，例如锁，信号量的依据主要是进程和线程。当发生不满足的条件的时候，会将进程或者线程丢到操作系统的调度队列中去等待，从而引发上下文的切换。我们知道操作系统上下文切换是非常耗时的，所以很难支持特别高的并发处理能力。利用这种方式设计出来的程序运行的时候，CPU利用率不高，且能看到大量的上下文切换。

 

假设常见的3GHZ CPU一次进程上下文切换时间为5us，则一秒钟如果切换超过20w次就会消耗一个CPU核。

 

针对等待IO的操作，是必须等待的，所以这个时候如果能快速的将CPU切换到别的需要CPU的程序中，则能大量的节省CPU消耗，从而提高并发的能力。协程主要就是利用干这个事情的，它将IO的操作封装掉，调用IO访问的时候如果发现不满足条件，则直接切换到可运行的协程上，由于是进程内部的快速切换，需要保持的现场特别少，并没有操作系统的其他开销所以特别高效。

 

针对访问公共内存导致的等待，能采取的办法就是减少共同访问的内存区域。对于实在是避免不了的互相协调，那也避免太频繁的切换。这种场景下，空间换时间是一个比较好的选择，也就是说两个程序协调的时候，如果每个处理的数据都协调并等待对方处理，这就意味着每次都需要进行上下文切换，如果大家将这种协调放在一个队列中，双方就可以依赖这个队列进行解耦，一方可以处理很多的数据放在队列中，而另一方等到有机会的时候就可以处理一批数据，从而减少切换（注：这个队列本身也是共享的数据，所以对这个队列的访问需要注意冲突的问题）。

 

Actor就是这样一种编程模型，每段程序原子程序叫一个Actor，这个Actor有一个信箱（就是一个数据队列），别人如果和它协调干一个事情的话，就给它发一个消息。信箱的主人就会收到这个消息，并进行处理。并且由于这个信箱的存在，所以也能解决双方处理速度不一致的匹配问题。

 

刚才提到，协程可以解决等待IO的问题（底层将IO的等待都封装掉），协程之间的通信或者说协调也可以使用类似的通知队列来实现。在go语言等语言中，这种队列称之为Channel，并且不像Actor模型（队列是隐含的，每个Actor都有），写的协程和读的协程之间的队列是单独定义的，并且和协程之间没有一对一的关系。如果将Actor的通知机制看成Queue的话，这种就是典型的Pub-Sub机制了。这种机制明细比Actor的那种更解耦，所以灵活性更大。但是带来的副作用就是用不好更容易出错。