进程与线程

1、多进程比多线程的缺点：

> It is difficult to share information between processes. Since the parent and
child don’t share memory (other than the read-only text segment), we must use
some form of interprocess communication in order to exchange information
between processes.
> Process creation with fork() is relatively expensive. Even with the copy-on-write
technique described in Section 24.2.2, the need to duplicate various process
attributes such as page tables and file descriptor tables means that a fork() call is
still time-consuming. Context-switch time may be lower for threads than for processes .
 

2、多线程比多进程的优势

> Sharing information between threads is easy and fast. It is just a matter of copying
data into shared (global or heap) variables. However, in order to avoid the
problems that can occur when multiple threads try to update the same information, we must employ the synchronization techniques.
> Thread creation is faster than process creation—typically, ten times faster or
better. (On Linux, threads are implemented using the clone() system call, and
Table 28-3, shows the differences in speed between fork() and clone().)
Thread creation is faster because many of the attributes that must be duplicated

 in a child created by fork() are instead shared between threads. In particular,
copy-on-write duplication of pages of memory is not required, nor is duplication of page tables. 

3、多线程比多进程缺点

Using threads can have some disadvantages compared to using processes:
> When programming with threads, we need to ensure that the functions we call are thread-safe or are called in a thread-safe manner.  Multiprocess applications don’t need to be concerned with this.
> A bug in one thread (e.g., modifying memory via an incorrect pointer) can damage all of the threads in the process, since they share the same address space and other attributes. By contrast, processes are more isolated from one another.
> Each thread is competing for use of the finite virtual address space of the host process. In particular, each thread’s stack and thread-specific data (or threadlocal storage) consumes a part of the process virtual address space, which is consequently unavailable for other threads. Although the available virtual address space is large (e.g., typically 3 GB on x86-32), this factor may be a significant limitation for processes employing large numbers of threads or
threads that require large amounts of memory. By contrast, separate processes can each employ the full range of available virtual memory (subject to the limitations of RAM and swap space).

4、需要额外考虑的点

The following are some other points that may influence our choice of threads
versus processes:
> Dealing with signals in a multithreaded application requires careful design. (As a general principle, it is usually desirable to avoid the use of signals in multithreaded programs.) 
> In a multithreaded application, all threads must be running the same program (although perhaps in different functions). In a multiprocess application, different processes can run different programs.
> Aside from data, threads also share certain other information (e.g., file descriptors, signal dispositions, current working directory, and user and group IDs). This may be an advantage or a disadvantage, depending on the application.

5、线程共享的属性

Besides global memory, threads also share a number of other attributes (i.e., these
attributes are global to a process, rather than specific to a thread). These attributes
include the following:
> process ID and parent process ID;
> process group ID and session ID;
> controlling terminal;
> process credentials (user and group IDs);
> open file descriptors;
> record locks created using fcntl();
> signal dispositions;
> file system–related information: umask, current working directory, and root
directory;
> interval timers (setitimer()) and POSIX timers (timer_create());
> System V semaphore undo (semadj) values (Section 47.8);
> resource limits;
> CPU time consumed (as returned by times());
> resources consumed (as returned by getrusage()); and
> nice value (set by setpriority() and nice()). 

6、线程不共享的属性

> thread ID;
> signal mask;
> thread-specific data;
> alternate signal stack (sigaltstack());
> the errno variable;
> floating-point environment (see fenv(3));
> realtime scheduling policy and priority;
> CPU affinity (Linux-specific);
> capabilities (Linux-specific); and
> stack (local variables and function call linkage information).

7、pthread_join和waitpid

> Threads are peers. Any thread in a process can use pthread_join() to join with
any other thread in the process. For example, if thread A creates thread B,
which creates thread C, then it is possible for thread A to join with thread C, or
vice versa. This differs from the hierarchical relationship between processes.
When a parent process creates a child using fork(), it is the only process that
can wait() on that child. There is no such relationship between the thread that
calls pthread_create() and the resulting new thread.
> There is no way of saying “join with any thread” (for processes, we can do this
using the call waitpid(–1, &status, options)); nor is there a way to do a nonblocking
join (analogous to the waitpid() WNOHANG flag). 

The limitation that pthread_join() can join only with a specific thread ID is
intentional. The idea is that a program should join only with the threads that it
“knows” about. The problem with a “join with any thread” operation stems from
the fact that there is no hierarchy of threads, so such an operation could indeed
join with any thread, including one that was privately created by a library function.
(The condition-variable technique that we show in Section 30.2.4 allows a
thread to join only with any other thread that it knows about.) As a consequence, 

the library would no longer be able to join with that thread in order to
obtain its status, and it would erroneously try to join with a thread ID that had
already been joined. In other words, a “join with any thread” operation is
incompatible with modular program design.