并发：进程与线程
使用基于进程的并发模型比基于进程的并发模型有哪些主要优点 基于线程，后者在什么情况下合适？
What are the main advantages of using a model for concurrency based on processes over one
based on threads and in what contexts is the latter appropriate?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
容错性和可扩展性是使用进程与线程的主要优点。
依赖于共享内存或仅在使用线程时可用的其他技术的系统，当您想在多台计算机上运行系统时将毫无用处。迟早您将需要在不同进程之间进行通信。
例如，当使用进程时，您被迫通过消息来处理通信，这就是 Erlang 处理通信的方式。数据不共享，因此不存在数据损坏的风险。
进程的另一个优点是它们可能会崩溃，并且您可以感到相对安全，因为您知道可以重新启动它们（甚至跨网络主机）。然而，如果一个线程崩溃，它可能会崩溃整个进程，这可能会导致整个应用程序崩溃。举例来说：如果 Erlang 进程崩溃，您只会丢失该电话或该 Web 请求等，而不是整个应用程序。
综上所述，操作系统进程也有许多缺点，这些缺点可能使它们更难使用，例如需要很长时间才能生成新进程。然而，Erlang 有它自己的进程概念，它非常轻量级。
话虽如此，这个讨论确实是一个研究课题。如果你想了解更多细节，可以给 Joe Armstrong 关于容错系统的论文]读一读，它解释了很多关于 Erlang 及其驱动哲学的内容。
Fault-tolerance and scalability are the main advantages of using Processes vs. Threads.
A system that relies on shared memory or some other kind of technology that is only available when using threads, will be useless when you want to run the system on multiple machines. Sooner or later you will need to communicate between different processes.
When using processes you are forced to deal with communication via messages, for example, this is the way Erlang handles communication. Data is not shared, so there is no risk of data corruption.
Another advantage of processes is that they can crash and you can feel relatively safe in the knowledge that you can just restart them (even across network hosts). However, if a thread crashes, it may crash the entire process, which may bring down your entire application. To illustrate: If an Erlang process crashes, you will only lose that phone call, or that webrequest, etc. Not the whole application.
In saying all this, OS processes also have many drawbacks that can make them harder to use, like the fact that it takes forever to spawn a new process. However, Erlang has it's own notion of processes, which are extremely lightweight.
With that said, this discussion is really a topic of research. If you want to get into more of the details, you can give Joe Armstrong's paper on fault-tolerant systems]1 a read, it explains a lot about Erlang and the philosophy that drives it.
使用基于流程的模型的缺点是速度会比较慢。您必须在程序的并发部分之间复制数据。
使用基于线程的模型的缺点是您可能会出错。这听起来可能很刻薄，但这是事实——向我展示基于线程的代码，我就会向你展示一个错误。我在已“正确”运行了 10 年的线程代码中发现了错误。
使用基于流程的模型有很多优点。这种分离迫使你根据协议和正式的沟通模式来思考，这意味着你更有可能做对。相互通信的进程更容易在多台机器上横向扩展。多个并发进程允许一个进程崩溃而不必使其他进程崩溃。
使用基于线程的模型的优点是速度快。
我更喜欢这两者中的哪一个可能是显而易见的，但如果不是：流程、一周中的每一天和周日两次。线程太难了：我还没有遇到过能够编写正确的多线程代码的人；那些声称能够做到这一点的人通常对这个空间还不够了解。
The disadvantage of using a process-based model is that it will be slower. You will have to copy data between the concurrent parts of your program.
The disadvantage of using a thread-based model is that you will probably get it wrong. It may sound mean, but it's true-- show me code based on threads and I'll show you a bug. I've found bugs in threaded code that has run "correctly" for 10 years.
The advantages of using a process-based model are numerous. The separation forces you to think in terms of protocols and formal communication patterns, which means its far more likely that you will get it right. Processes communicating with each other are easier to scale out across multiple machines. Multiple concurrent processes allows one process to crash without necessarily crashing the others.
The advantage of using a thread-based model is that it is fast.
It may be obvious which of the two I prefer, but in case it isn't: processes, every day of the week and twice on Sunday. Threads are too hard: I haven't ever met anybody who could write correct multi-threaded code; those that claim to be able to usually don't know enough about the space yet.
在这种情况下，进程彼此更加独立，而线程共享一些资源，例如内存。但在一般情况下，线程比进程更轻量。
Erlang 进程与操作系统进程不同。 Erlang 进程非常轻量级，Erlang 可以在同一个操作系统线程中拥有许多 Erlang 进程。请参阅 从技术上讲，为什么 Erlang 中的进程比操作系统线程？
In this case Processes are more independent of eachother, while Threads shares some resources e.g. memory. But in a general case Threads are more light-weight than Processes.
Erlang Processes is not the same thing as OS Processes. Erlang Processes are very light-weight and Erlang can have many Erlang Processes within the same OS Thread. See Technically why is processes in Erlang more efficient than OS threads?
首先也是最重要的，进程与线程的不同之处主要在于它们的内存处理方式：
进程有自己的隔离内存。
进程可以有多个线程。
进程在操作系统级别上相互隔离。
线程与进程中的同级线程共享内存。
（这通常是不可取的。有一些库和方法可以解决这个问题，但这通常是操作系统线程之上的人造层。）
内存是最重要的辨别因素，因为它具有某些含义：
使用流程可以为您提供良好（或最终）的封装。由于进程间通信需要特殊的努力，因此您将被迫定义一个干净的接口。将应用程序的某些部分从主可执行文件中分离出来是个好主意。也许你可以像这样分割依赖关系。
例如
Process_RobotAi <-> Process_RobotControl与控制组件相比，人工智能将具有截然不同的依赖性。界面可能很简单：
Process_RobotAI --DriveXY--> Process_RobotControl。也许你改变了机器人平台。您只需使用这个简单的接口实现一个新的
RobotControl可执行文件即可。您无需触及甚至无需重新编译 AI 组件中的任何内容。出于同样的原因，在大多数情况下它也会加快编译速度。
编辑：为了完整起见，我将无耻地添加其他人提醒我的内容：
崩溃的进程不会（必然）导致整个应用程序崩溃。
一般来说：
1 和 2 是极端且无需思考的情况，介于两者之间的所有情况都必须单独决定。
有关大量使用 IPC/RPC 的系统的良好（或很棒）示例，请查看 ros。
First and foremost, processes differ from threads mostly in the way their memory is handled:
Processes have their own isolated memory.
Processes can have multiple threads.
Processes are isolated from each other on the operating system level.
Threads share their memory with their peers in the process.
(This is often undesirable. There are libraries and methods out there to remedy this, but that is usually an artificial layer over operating system threads.)
The memory thing is the most important discerning factor, as it has certain implications:
Using processes gives you good (or ultimate) encapsulation. Since inter process communication needs special effort, you will be forced to define a clean interface. It is a good idea to break certain parts of your application out of the main executable. Maybe you can split dependencies like that.
e.g.
Process_RobotAi <-> Process_RobotControlThe AI will have vastly different dependencies compared to the control component. The interface might be simple:
Process_RobotAI --DriveXY--> Process_RobotControl.Maybe you change the robot platform. You only have to implement a new
RobotControlexecutable with that simple interface. You don't have to touch or even recompile anything in your AI component.It will also, for the same reasons, speed up compilation in most cases.
Edit: Just for completeness I will shamelessly add what the others have reminded me of :
A crashing process does not (necessarily) crash your whole application.
In General:
1 and 2 are the extreme and no-brainer scenarios, everything in between must be decided individually.
For a good (or awesome) example of a system that uses IPC/RPC heavily, have a look at ros.