PROCESSES, THREADS, AND PTHREADS
Recall from Chapter 2 that in shared-memory programming, a thread is somewhat analogous to a process in MPI programming. However, it can, in principle, be
“lighter-weight.” A process is an instance of a running (or suspended) program. In addition to its executable, it consists of the following:
.. A block of memory for the stack
. A block of memory for the heap
Descriptors of resources that the system has allocated for the process—for
example, file descriptors
Security information—for example, information about which hardware and software resources the process can access
Information about the state of the process, such as whether the process is ready to run or is waiting on a resource, the content of the registers including the program counter, and so on
In most systems, by default, a process’ memory blocks are private: another process can’t directly access the memory of a process unless the operating system intervenes. This makes sense. If you’re using a text editor to write a program (one process— the running text editor), you don’t want your browser (another process) overwriting your text editor’s memory. This is even more crucial in a multiuser environment. One user’s processes shouldn’t be allowed access to the memory of another user’s processes.
However, this isn’t what we want when we’re running shared-memory programs. At a minimum, we’d like certain variables to be available to multiple processes, so shared-memory “processes” typically allow much easier access to each others’ mem-ory. They also often share things such as access to stdout. In fact, it’s conceivable that they share pretty much everything that’s process specific, except their stacks and their program counters. This can be relatively easily arranged by starting a single process and then having the process start these “lighter-weight” processes. For this reason, they’re often called light-weight processes.
The more commonly used term, thread, comes from the concept of “thread of control.” A thread of control is just a sequence of statements in a program. The term suggests a stream of control in a single process, and in a shared-memory program a single process may have multiple threads of control.
As we noted earlier, in this chapter the particular implementation of threads that we’ll be using is called POSIX threads or, more often, Pthreads. POSIX  is a standard for Unix-like operating systems—for example, Linux and Mac OS X. It specifies a variety of facilities that should be available in such systems. In par-ticular, it specifies an application programming interface (API) for multithreaded programming.
Pthreads is not a programming language (such as C or Java). Rather, like MPI, Pthreads specifies a library that can be linked with C programs. Unlike MPI, the Pthreads API is only available on POSIX systems—Linux, Mac OS X, Solaris, HPUX, and so on. Also unlike MPI, there are a number of other widely used spec-ifications for multithreaded programming: Java threads, Windows threads, Solaris threads. However, all of the thread specifications support the same basic ideas, so once you’ve learned how to program in Pthreads, it won’t be difficult to learn how to program another thread API.
Since Pthreads is a C library, it can, in principle, be used in C++ programs. However, there is an effort underway to develop a C++ standard (C++0x) for shared-memory programming. It may make sense to use it rather than Pthreads if you’re writing C++ programs.