If the mission of the operating system is to manage computing resources on behalf of processes, then it must be continuously informed about the status of each process and resource. The approach commonly followed to represent this information is to create and update status tables for each relevant entity, like memory, I/O devices, files and processes. Memory tables, for example, may contain information about the allocation of main and secondary (virtual) memory for each process, authorization attributes for accessing memory areas shared among different processes, etc. I/O tables may have entries stating the availability of a device or its assignment to a process, the status of I/O operations being executed, the location of memory buffers used for them, etc. File tables provide info about location and status of files (of course, what else? more on this later). Finally, process tables store the data the OS needs to manage processes. At least part of the process control data structure is always maintained in main memory, though its exact location and configuration varies with the OS and the memory management technique it uses. In the following we'll refer by process image to the complete physical manifestation of a process, which includes instructions, program data areas (both static and dynamic - e.g. at least a stack for procedure calls and parameter passing) and the process management information. We'll call this last set the process control block (PCB).
The role of the PCBs is central in process management: they are accessed and/or modified by most OS utilities, including those involved with scheduling, memory and I/O resource access and performance monitoring. It can be said that the set of the PCBs defines the current state of the operating system. Data structuring for processes is often done in terms of PCBs. For example, pointers to other PCBs inside a PCB allow the creation of those queues of processes in various scheduling states (``ready'', ``blocked'', etc.) that we previously mentioned.
In modern sophisticated multitasking systems the PCB stores many different items of data, all needed for correct and efficient process management. Though the details of these structures are obviously system-dependent, we can identify some very common parts, and classify them in three main categories:
Process identification data always include a unique identifier for the process (almost invariably an integer number) and, in a multiuser-multitasking system, data like the identifier the parent process, user identifier, user group identifier, etc. The process id is particularly relevant, since it's often used to cross-reference the OS tables defined above, e.g. allowing to identify which process is using which I/O devices, or memory areas.
Processor state data are those pieces of information that define the status of a process when it's suspended, allowing the OS to restart it later and still execute correctly. This always include the content of the CPU general-purpose registers, the CPU process status word, stack and frame pointers etc.
Process control information is used by the OS to manage the process itself. This include