pin*_*nto 7 multithreading multiprocessing
我正在为Linux设计一个专用的syslog-processing守护进程,它需要健壮且可扩展,我正在讨论多线程与多进程.
多线程的明显反对意见是复杂性和令人讨厌的错误.由于IPC通信和上下文切换,多进程可能会影响性能.
您会推荐基于流程的系统(如Apache)还是多线程方法？
小智 21
它们都可以以自己的方式复杂和复杂.
你也可以.在宏伟的计划中,你选择哪个并不重要.重要的是你做得多好.因此:
做你最有经验的事.或者,如果您领导一个团队,请执行团队最有经验的团队.
---线程!---
我做了很多线程编程,我喜欢它的一部分,我不喜欢它的一部分.我学到了很多东西,现在通常可以编写一个多线程的应用程序而不会有太多的痛苦,但它必须以非常具体的方式编写.即:
1)必须使用非常明确定义的数据边界编写,这些数据边界是100%线程安全的.否则,任何条件可能发生,会发生,当你有一个调试器周围铺设..加上调试多线程代码是这样窥视到薛定谔的盒子可能不是......通过寻找在那里,其他线程可能会或可能不会有有时间处理更多.
2)必须用强调机器的测试代码编写.许多多线程系统只在机器受到很大压力时显示它们的错误.
3)必须有一些非常聪明的人拥有数据交换代码.如果有任何方法可以创建一个快捷方式,一些开发人员可能会成功,你将有一个错误的错误.
4)必须有一个全能的情况,重新启动应用程序,而不用大惊小怪.这是因为某些线程问题导致生产代码中断.简而言之:节目必须继续.
- -跨进程! - -
我有一个基于进程的线程经验较少,但最近一直在做Windows中的某些跨进程的东西(其中IPC是Web服务调用...呜!),它是比较干净,简单,但我遵循一些规则这里也是.总的来说,进程间通信将更加无错误,因为程序很好地接收来自外部世界的输入......并且这些传输机制通常是异步的.无论如何...
1)定义明确的流程边界和沟通机制.只要边框清晰,并且在这些边界处有大量验证和错误检查代码,就可以通过TCP或Web服务或管道或任何其他方式发送消息/事件.
2)做好瓶颈准备.代码宽恕非常重要.我的意思是,有时候你无法写入那个管道.您必须能够在没有应用程序锁定/抛出异常的情况下重新排队并重试这些消息.
3)一般来说会有更多代码,因为跨越流程边界传输数据意味着您必须以某种方式对其进行序列化.这可能是问题的根源,尤其是当您开始维护和更改该代码时.
希望这可以帮助.
取决于您要使用的编程语言（以及哪些库）。就我个人而言，我会选择多线程，因为我知道与线程相关的问题（以及如何解决它们）。
如果您想在多台计算机上运行守护程序并在它们之间分配负载，多重处理可能会对您有所帮助，但我认为这不是一个主要问题。