群里今天聊服务器到底该不该多线程？

tonykee

很多人支持做单线程服务器，最多个加多进程，不提倡多线程，原因是共享数据的问题（锁和数据拷贝）是多线程最大的麻烦，也有不少人支持多线程，认为拿多线程做冲突少的业务（但视乎太理想了），各执一词好像都很有道理。

我之前做的服务器的微型版是多线程的，之前也碰到过这些问题确实很头痛，我也有点被动摇了
有人能对这个话题发表一些看法吗？

快乐杰克

建议回群继续讨论,在这里你不会有更多收获.

tonykee

...

970361

就像开汽车，如果技术好就可以开的足够快，没把握就开慢点。

tonykee

恩，我觉得这里面还是复杂度和开发成本的问题，大多数人都不愿意为提高那么一点点性能而花费那么大的代价，没有同样功能的实现去比较，确实不好说，但很多服务器都是单线程的，而且也获得了成功，这是事实，看来也该退而其次求稳不求快了。

flying5

970361: Re:群里今天聊服务器到底该不该多线程？

就像开汽车，如果技术好就可以开的足够快，没把握就开慢点。

赞同，自己能力足够的时候用多线程

clayman

哦，tonykee兄有什么好群，加我一个啊

OpenGPU

是指pthread级别的Multi-threading么？

从安全角度来说，Thread之间通信是如果一个Thread出事了，那整个Process内的所有Thread就全完蛋了。如果要使多进程的话，那Precess之间可以用OS来隔离。比如你把聊天系统、货币系统、对战系统等不同的功能模块分到不同的进程中，就算一个功能挂了，也不会导致服务器全挂。

从性能角度来说，当然是多线程胜出了，因为Process的切换时OS来处理的上千个Cycle的事情，而在大型的多处理器Server上，Thread Switch可以由HW来处理，0 Cycle的切换代价，这一点尤其是在安装了SMT CPU的Server上尤为明显。还有一点就是Thread之间通信的代价小于Process之间通信的代价。


至于锁的问题，可以考虑用用一个专门处理仲裁的Thread来分配任务，实现的时候可以考虑由他来启动拿到任务的THread，然后等待这些Thread计算好了之后回收数据。这相当于仲裁锁的行为了。但是这种机制并不能替代锁，锁本身是保证 Sequential Consistency的一种机制，在通信的时候是必须的，在原理上，这问题来源于图灵机之间的通讯，是数学问题。这机制只能简化抢锁的行为。

---------------------------------------------------------------------------------------------

OpenGPU.org（http://www.opengpu.org/bbs/index.php）主要聚焦图形硬件（包括GPU体系结构）以及各种图形算法

yahle

如果多进程是为了解决多线程时访问共享数据时的锁冲突，那么，多进程条件下如何维护一些共享数据呢？

ych1

单线程，多进程服务器。都是从云飞blog那里看来的把？

多核时代，多线程是必须的。

80%的数据共享问题属于“先知”问题，也就是脑子里面光想，这样做将来会不会出现xx问题，比如共享冲突。而后就很沮丧的自我否定了。

冲突是不可能避免的，如果可以，先解决食堂排队抢饭问题先。有的只是针对实际情况的折中方案。

传统的编程语言，（传统也就是指最多人用，最傻瓜化等）在并行问题上缺乏有效的支持，或者说在并行问题上要求编程者有较高的技术水平。

一些小众语言对并行考虑较好，如Erlang（虽然觉得它有点反胃），D语言等，用来做服务器是比较好的选择。

数据共享是竞争问题，不可避免。但繁琐的数据拷贝是弱智问题，设计者的失误。解决数据共享的一个思路是，没有共享数据（假设你内存足够多），例如纯函数式的语法。此外还有大牛们在弄得锁无关数据结构等。

共享数据不可消除，但却是可控。control才是软件开发的关键。控制不了，在好的技术都是废物。

最后，这个版块，几乎不忍心来看。。。 相对来说还是 策划版 娱乐性较强。