Concurrency: Processes vs Threads

Question

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?

Answer 1

First and foremost, processes differ from threads mostly in the way their memory is handled:

Process = n*Thread + memory region  (n>=1)

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:

1. Exchanging data between processes is slower than between threads. Breaking the process isolation always requires some involvement of kernel calls and memory remapping.
2. Threads are more lightweight than processes. The operating system has to allocate resources and do memory management for each process.
3. Using processes gives you memory isolation and synchronization. Common problems with access to memory shared between threads do not concern you. Since you have to make a special effort to share data between processes, you will most likely sync automatically with that.

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_RobotControl The 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 RobotControl executable 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. Want to create something highly concurrent or synchronuous, like an algorithm with n>>1 instances running in parallel and sharing data, use threads.
2. Have a system with multiple components that do not need to share data or algorithms, nor do they exchange data too often, use processes. If you use a RPC library for the inter process communication, you get a network-distributable solution at no extra cost.

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.