How to choose between process and threads

Question

Possible Duplicate:
Threads vs Processes in Linux

To implement multi-tasks programs we could use either processes or threads.
My question is how to choose between these methods ? does it have an effect on system memory or cpu usage ?

Answer 1

If your application will consist of separate, individually-usable components that communicate through well-defined protocols, each of which performs jobs that can individually succeed or fail without complicating the logic of the other components, then it's perfectly reasonable to write an application that utilizes multiple processes. A good example of an application that could be constructed this way is a MTA (mail transport agent).

If on the other hand the concurrency will involve lots of shared data/state where continuance of one flow of execution depends on the result of another, you really should be using threads. The biggest advantages of threads over processes are:

1. Access to efficient synchronization objects without having to setup your own shared memory for them to live in.
2. Atomicity of the process: it's impossible for some threads to be terminated by factors beyond your control (like the user issuing a kill command) and others to live on. This is very important because in applications with complex synchronization requirements, unexpected asynchronous termination of one flow of execution (especially, for example, with a lock still held) could make it impossible for others to continue safely.
3. The existence of threads is completely transparent to other parts of the program that don't want/need to be aware of them (whereas creating child processes has global state issues with respect to waiting for exit status, SIGCHLD, etc.).

In addition, threads have some other minor practical advantages:

1. Faster creation/exit times (usually 2-3x faster than fork and at least 20x faster than fork+exec).
2. Improved ability for the kernel to make scheduling fair between applications.
3. (And probably some others I'm not thinking of...)

And a few practical disadvantages:

1. Unnecessary contention for locks in standard library functions like malloc.
2. Ability of buggy code in one flow of execution to corrupt the state of others.
3. Inability to have different privilege levels for each thread.

The only time I would consider using separate processes instead of threads when the conceptual best-fit for the problem is threads is in cases where using separate processes provides a huge advantage to your security model (i.e. privilege separation ala vsftpd and openssh).

Answer 2

Processes are relatively heavy-weight (use more system resources). However, they do offer isolation from one another (a crash of one worker process will not directly affect other worker processes, though if a process crashes and has locked shared resources that are not released, that would impact other processes). The single thread of execution model is easier for less experienced programmers.

Threads are relatively light-weight (use less system resources). If you don't follow proper thread programming techniques, the program can behave unpredictably (having said that, proper thread programming techniques are well documented and well worth learning). Threads are not isolated from each other. One thread can corrupt another thread's memory, and a crash of one thread can affect other threads.

The final choice depends on your needs, and your skills, and the choice is by no means obvious. For example, many browsers are multi-threaded. The threads are lightweight, allowing the browser to access many resources and handle many open tabs, without consuming too many resources. Google Chrome, however, chose to create a process-per-tab. That consumes more resources, however offers isolation between the tabs. If a web page triggers a bug in a tab, or if a plugin crashes a tab, the other tabs are not affected.