| On HP-UX operating system releases prior to 10.10, the kernel scheduled a process to run on the hardware to accomplish its programmatic tasks. By this model, a process lived a very solitary life and the programmer did not have to be concerned with the coordination of access to the process's private system resources. While the kernel provided many forms of sharing between process views (shared memory, shared file access, memory-mapped files, and shared libraries to name but a few), process-private data could only be used or modified by the process's single thread of execution. A process could only do one thing at a time. If it was blocking (or sleeping) on a physical action, such as waiting for operator input or a tape drive to rewind, then it was said to be in a wait-state or sleeping, and only when the blocking action was completed could it perform its next instruction. In the early days of computing this model served quite well, since most systems had very limited resources, single processors, and comparatively slow response times. System architectures progressed to include multiple processors under simultaneous control of a single kernel, referred to as symmetrical multiprocessing (SMP) systems (see Chapter 12, "Multiprocessing and HP-UX," for additional details on this aspect of the kernel). The next step was to devise a methodology whereby a single program could take advantage of SMP parallelism and execute tasks on several CPUs at the same time. This required a new breed of programmatic logic and gave rise to many innovations in operating system design. The challenge of parallelism with respect to the management of a process and its execution brought about the creation of multithreaded kernels. Thread-based structures were first introduced into the HP-UX kernel with the 10.10 release (the initial threading of the kernel supported only a single thread per process, but it was a first step). With the release of HP-UX 11.0, the kernel became truly multithreaded; that is, a single process could have multiple user-space/kernel-space thread pairs performing tasks in parallel if it was on a SMP system. Even on a uniprocessor (UP) system, a process could spawn multiple threads, and they could compete for system resources: perhaps one could sleep waiting on user input while another processed existing data. A thread-based kernel manages a client program by first creating a unique process container by which to track and manage the global attributes and allotted system resources of the program. Next, it creates one or more threads to implement the program's instructions. These threads are schedulable entities. In effect, the venerable process was promoted to a management position instead of actually doing the work, it now owns the resources and supervises and coordinates the actions of its subordinate threads. An operating system such as HP-UX (even before the implementation of kernel threads) was said to be multiple-process or multiple-tasking in reference to its ability to switch or timeslice between completely independent sets of process instructions. Each process had use of the system's resources and ran in a private context without knowledge or interaction with other processes resident on the system. The kernel switched context from one to another, carefully managing the system resources so that each process had its own private view of "reality" and so that they did not disturb the view of their neighbors. The kernel maintained peace in the community and made each process feel as if it were king of the hill. This type of process management required heavyweight context-switching system calls. A threaded process is one in which there may be several threads of execution simultaneously contending for system resources. Unlike in the older multiprocess environment, a single process may have one or more concurrent threads. Multiple threads of the same process (called siblings) share the same system resource view. They share the same code, most of the same data space (each thread does have its own stack space and user area), and the same libraries and system resources. Since all the threads of a process are playing in the same sandbox, it becomes the responsibility of the programmer to develop strategies to assure that sibling don't step on each other. To help in this task, many programming aids and libraries have been developed. The thread has become the schedulable entity and working incarnation of the program's instructions and logic. Today many operating system kernels (including HP-UX) operate in a multiprocess and multithreaded environment. The kernel must manage many different process contexts and also must manage processes with multiple threads. To accomplish this, the kernel considers individual threads, not processes, for scheduling. The thread becomes the active, working, schedulable entity for kernel management. This change in behavior between the process-centric and the thread-centric view of running a program is a seminal point in the evolution of operating system design. In HP-UX, the kernel must keep track of all active processes and each of their individual threads. This is accomplished by the creation of what many feel are the two most fundamental data structures in the operating system kernel: the process table and the kernel thread table. | 