Process control block

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Process Control Block (PCB, also called Task Controlling Block,[1] Task Struct, or Switchframe) is a data structure in the operating system kernel containing the information needed to manage a particular process. The PCB is "the manifestation of a process in an operating system".[2]

Role[edit]

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.

Structure[edit]

In modern sophisticated multitasking systems, the PCB stores many different items of data, all needed for correct and efficient process management.[1] 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
  • Processor state data
  • Process control data

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 of 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 includes the content of the CPU general-purpose registers, the CPU process status word, stack and frame pointers etc. During context switch, the running process is stopped and another process is given a chance to run. The kernel must stop the execution of the running process, copy out the values in hardware registers to its PCB, and update the hardware registers with the values from the PCB of the new process.

Process control information is used by the OS to manage the process itself. This includes:

  • The process scheduling state, e.g. in terms of "ready", "suspended", etc., and other scheduling information as well, like a priority value, the amount of time elapsed since the process gained control of the CPU or since it was suspended. Also, in case of a suspended process, event identification data must be recorded for the event the process is waiting for.
  • Process structuring information: process's children id's, or the id's of other processes related to the current one in some functional way, which may be represented as a queue, a ring or other data structures.
  • Interprocess communication information: various flags, signals and messages associated with the communication among independent processes may be stored in the PCB.
  • Process privileges, in terms of allowed/unallowed access to system resources.
  • Accounting information, such as when the process was last run, how much CPU time it has accumulated, etc.

Location[edit]

Since PCB contains the critical information for the process, it must be kept in an area of memory protected from normal user access. In some operating systems the PCB is placed in the beginning of the kernel stack of the process since that is a convenient protected location.[3]

See also[edit]

Notes[edit]

  1. ^ a b Gagne, Abraham Silberschatz, Peter Baer Galvin, Greg. Operating system concepts (9th ed. ed.). Hoboken, N.J.: Wiley. pp. 107–108. ISBN 9781118063330. 
  2. ^ Deitel, Harvey M. (1984) [1982]. An introduction to operating systems (revisited first edition ed.). Addison-Wesley. p. 673. ISBN 0-201-14502-2.  pages 57-58
  3. ^ Yong, Zhang, "Breaking through the Maximum Process Number", Linux Journal, 1 Jan 2004, [1].