c++应用网络编程之七基于线程的模式

一、基于线程的模式

在传统的IO开发中，为了应对并发的IO通信存在，最简单的方式是每一次的IO操作都启动一个线程来进行管理，而这种传统的形式就是基于线程的网络编程模式。提到这种模式就需要明白，线程在IO操作中到底起到了什么作用？其实就是一点，同步。使用线程可以轻松的实现同步机制。也就是说，通过多个线程的操作来提供IO的并行操作。但多线程的缺点也因此而暴露出来，因为一般情况下，在系统中线程的数量是有上限的。同时，即使没有达到上限，它也有一个性能合理调度上限。
学习过多线程编程的都知道，不是线程越多效率越高。另外在前面，提到过，上层的异步操作，大多也都是通过多线程来实现的。如果是这种情况，异步的本质其实就是在线程同步的基础上实现的。

二、线程模式和事件模式的对比

事件模式的优势在于天然的并发性而多线程程的优势在于开发者的易理解性。它们在服务端的应用开发上，一直存在着巨大的争议。如果想真正搞明白二者的不同或者说应用场景的使用，就必须深入到整个计算机的体系结构和OS体系内进行分析。这里不打算展开那么多那么深，只从应用的角度分析一下。
事件驱动的灵活性，允许它可以在任何情况展开使用。举一个简单的例子，键盘的中断机制，它其实就是一种事件驱动。开发者可以在任何情况下在代码中嵌入对键盘操作的处理，而无须引入任何的场景限制。它的灵活性使得其在应用上展开出一种随意性，而这种随意性导致整体代码的逻辑流程的散乱性的结果。而这种结果又恰恰非软件工程所希望看到的。
而多线程本质上仍然是人类同步工作的一种体现，可以简单的理解为把工作效率和性能提升的一种手段。（当然，多线程程同步也引入了数据共享和同步等副作用机制）这种并行与事件并行可以理解为对单体的运行效率与整体的运行效率的一种不同。事件驱动更倾向于在某一IO操作上实现更强的并发，而多线程更倾向于从整体上达到更高的并发。这两个并无本质的区别，可以说是一致的。
事件驱动模式更适合于逻辑关联较低甚至没有的情况下的工作场景，而多线程则反之。而在实际的应用开发中，这两者往往不是单独存在的，也就是说使用一种处理机制来完成实际的应用，常常有力不从心的感觉。那么，我们是不是可以提出一个解决思路，就是可不可以把事件和多线程模式搞在一起？答案当然是肯定的。
结合两种模式，既可以解决事件的非逻辑性问题，又可以解决多线程的同步共享问题。但这带来的更可能是编程者的复杂性。而复杂性的问题，又往往会导致，可能理想是丰满的，现实是骨感的。也就是说，既没有解决事件的非逻辑性，又带来了多线程的同步共享问题。
但这并不代表它的优势的泯灭。既然开发者的参差不齐导致的对复杂问题的处理的力不从心，那么就在底层解决或者实现一种框架一门语言来搞定这个问题。这在一些函数编程语言中，进行了有益的尝试。由于篇幅的原因这里不做展开。

三、多线程的并发

并发模型一般都是基于事件的处理的，它需要一系列的队列或者邮箱等这种机制来支持，前文提到的IOCP其实就是需要一个队列来实现事件的处理。而在前面提到的多线程的数据并发模型中提到过Actor和CSP模型，包括后来还提出的Pi算子等并发模型。这些都是并发的基础支持。从这一点也可以看出来，在并发中，无论是事件还是多线程都是要基于相同的处理模型来处理数据。

四、总结

面对问题，最主要的是分析问题产生的原因，找出解决的方法，实现解决的过程即分析问题，解决问题，验证结果。如果没有一套理论体系来支持，那么只能是尝试，反复不断的尝试或者说有经验者在经验的指导下的尝试。如果是科学研究碰触到的全新的领域，如此做法，未尝不是一种好的办法。但如果是在既有的知识体系中，再做如此行为，就有些盲目努力的感觉了。
时事不同，则指导思想不同。与时俱进，实事求是罢了！