Why should I use a thread vs using a process?

Question

I'm a newbie at this so please forgive me for my ignorance. Separating different parts of a program into different processes seems (to me) to make a more elegant program then just threading everything. In what scenario would it make sense to make things run on a thread vs separating the program into different processes? When should I use a thread?

---

Edit:

Anything on how (or if) they act differently with single core and multi core would also be helpful.

Answer 1

You'd prefer multiple threads over multiple processes for two reasons:

1. Inter-thread communication (sharing data etc.) is significantly simpler to program than inter-process communication.
2. Context switches between threads are faster than between processes. That is, it's quicker for the OS to stop one thread and start running another than do the same with two processes.

Example:

Applications with GUIs typically use one thread for the GUI and others for background computation. The spellchecker in MS Office, for example, is a separate thread from the one running the Office user interface. In such applications, using multiple processes instead would result in slower performance and code that's tough to write and maintain.

Answer 2

I assume you already know you need a thread or a process, so I'd say the main reason to pick one over the other would be data sharing.

Use of a process means you also need Inter Process Communication (IPC) to get data in and out of the process. This is a good thing if the process is to be isolated though.

Answer 3

Well apart from advantages of using thread over process, like:

Advantages:

• Much quicker to create a thread than a process.
• Much quicker to switch between threads than to switch between processes.
• Threads share data easily

Consider few disadvantages too:

• No security between threads.
• One thread can stomp on another thread's data.
• If one thread blocks, all threads in task block.

As to the important part of your question "When should I use a thread?"

Well you should consider few facts that a threads should not alter the semantics of a program. They simply change the timing of operations. As a result, they are almost always used as an elegant solution to performance related problems. Here are some examples of situations where you might use threads:

• Doing lengthy processing: When a windows application is calculating it cannot process any more messages. As a result, the display cannot be updated.
• Doing background processing: Some tasks may not be time critical, but need to execute continuously.
• Doing I/O work: I/O to disk or to network can have unpredictable delays. Threads allow you to ensure that I/O latency does not delay unrelated parts of your application.

Answer 4

In Windows world, a process is not an alternative to a thread. Process is just a new address space and security context for one or more threads. Windows thread scheduler only knows about threads. So the question would be "Why should I create a new address space and put a new thread there?".

A new process means completely new virtual address space, new security context therefore creating one requires some work. Context switch between threads on different processes requires OS to remap virtual address space and do a TLB flush. So there is a performance downside of having threads on multiple processes.

Threads on the same process are much more lightweight. They reside on the same memory space and they can share handles, security context. Switching between threads on the same process is much faster because OS only switches registers, not memory mapping.

On the other hand threads on same process are not protected against each other. Threads need to be careful on not to step on other threads' toes. If a thread crashes (unhandled exception), your process hence all other threads in that process will crash. Think of Flash plugin crashing IE. That's why Google Chrome hosts Flash in a separate process, if it crashes Chrome survives.

The performance advantage of threads is one of the reasons why Windows groups many "trusted" services in a few "svchost.exe" processes.

When your process exits, the threads you created are terminated too. If you don't want that you have to use a process.

Answer 5

You sure don't sound like a newbie. It's an excellent observation that processes are, in many ways, more elegant. Threads are basically an optimization to avoid too many transitions or too much communication between memory spaces.

Superficially using threads may also seem like it makes your program easier to read and write, because you can share variables and memory between the threads freely. In practice, doing that requires very careful attention to avoid race conditions or deadlocks.

There are operating-system kernels (most notably L4) that try very hard to improve the efficiency of inter-process communication. For such systems one could probably make a convincing argument that threads are pointless.

Answer 6

In addition to the other answers, maintaining and deploying a single process is a lot simpler than having a few executables.

One would use multiple processes/executables to provide a well-defined interface/decoupling so that one part or the other can be reused or reimplemented more easily than keeping all the functionality in one process.

Answer 7

I agree to most of the answers above. But speaking from design perspective i would rather go for a thread when i want set of logically co-related operations to be carried out parallel. For example if you run a word processor there will be one thread running in foreground as an editor and other thread running in background auto saving the document at regular intervals so no one would design a process to do that auto saving task separately.