多线程的思考

这些东西是平时遇到的, 觉得有一定的价值, 所以记录下来, 以后遇到类似的问题可以查阅, 同时分享出来也能方便需要的人, 转载请注明来自RingOfTheC[ring.of.the.c@gmail.com]

 

ps:有件事我忘记说明, 我是游戏服务器程序员, 工作是在linux, 本文中很多观点只适合我的工作环境, 并不适合windows下的朋友, 谢谢.

 

 

1. 为什么要使用多线程?
        a. 更好的利用CPU的资源.
        b. 服务器端我想不到其他原因.

2. 问题的由来?
         a. 抢占式
         b. 共享内存

        CPU对进程的调度是抢占式的 [这里先假设系统中所有的进程都是单线程模式的], 没有使用任何同步措施, 没问题, 为什么, 因为没有共享内存. Lua等动态语言中多个执行流共享内存, 但是没有使用任何同步措施, 也没问题, 因为不是抢占式调度.
          多线程的问题在于这两者的共存, 一个线程在某一随机点停下来时的机器状态快照和在后来某时刻在这一点恢复时的机器状态快照可能天差地别, 但是程序依然依赖于停止前的那张状态快照继续执行, 这样就造成了错误.

 

3. 对于多线程编程的基本看法?
        我个人在这个问题上的看法是: 使用多进程代替或者在极度清晰的情况下限制性的使用线程. 前者是选择抢占式而放弃共享内存, 后者不是一种具体的方法, 而是为了表达一种想正确设计多线程程序很难的意思, 除非你知道自己想干什么, 不然还是回到第一种方案.
        放弃企图提供一种计算框架的想法, 合理使用多线程是一个设计问题, 而不是一个程序技术问题, 它的困难程序取决于企图解决的问题的特性和复杂度, 往往这些问题是一些本质性的复杂, 并不存在完美的或者是一致的解决方法, 就像没有一个"万能软件"一样.
        个人认为将多线程问题的彻底解决方案留给一个尚未出名或者是尚未出生的天才. 这样想并不丢人, 因为咱们的世界, 不是本来就是有了瓦特, 爱迪生, 牛顿这样的人, 才能大踏步的前进么?

4. 在你认同我的第3条看法后, 我觉得有一些观点可以分享一下
        1. CPU多核了, 计算资源增多了. 但是一定要在一个程序中来尽量发挥计算资源呢? 为什么不是职责分明, 通过多个程序的合作来达到同样的目地呢? 通过程序合作的系统带给程序设计上的礼物是, 它将比任何一个设计模式更好的让你的系统解耦, 这是最好的办法了.
        2. 进程间通信没有想象的那么慢, 除非在实际中你碰到了因为进程间通信效率引起的大问题, 那么首先应该怀疑自己的模块划分问题? 是不是将同一个模块划到了两个进程中造成这样的大量消息交互; 第二, 你真的确定遇到的问题是因为进程间通信效率引起的么? 至少我到现在还没听说过呢.
         3. socket通信方式是最好的进程间通信, 选择它的附带奖励是你的系统天然支持分布式, 如果你用socket通信方式组织你的一系列合作的程序, 你就可以自豪的告诉别人:"我这是云系统", 云是啥, 老外说的好, 云就是让分布式听起来更性感点.