One might argue that in general processes are more ?exible than threads. For one thing, they can live in two different machines, and communicate via sockets; they are easy to spawn remotely (e.g. ssh foo.cs.umass.edu "ls -l"); etc. However, using processes requires explicit com- munication and risks hackery. Threads also have their own problems: because they communicate through shared memory, they must run on the same machine and they require thread-safe code.

So even though threads are faster, they are much harder to program. In a sense, we can say that processes are far more robust than threads, since they are completely isolated from other another. Threads, on the other hand, are not that safe, since whenever one thread crashes the whole process terminates.

When comparing processes and threads, we can also analyze the cost of context switches. When- ever we need to switch between two processes, we must invalidate the TLB cache (the so-called TLB shootdown; see Section 6.2.3). Because warming up the TLB takes time, context switches for processes are slower.

On the other hand, when we switch between two threads, it is not necessary to invalidate the TLB, because all threads share the same address space, and thus have the same contents in the cache. In other words, on many operating systems, the cost of switching between threads is much smaller than the cost of switching between processes. Most large-scale systems use a mixture of processes and threads:

threads within a process on one server, communicating via a network socket to similar processes on other servers.