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

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.

Answer 2

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?

Answer 3

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.

Answer 4

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.