Learning Center
Plans & pricing Sign in
Sign Out

Process Description and Control


Principles of Operating Systems

More Info
									Chapter 3:
Process Description and Control

         CS 472 Operating Systems
    Indiana University – Purdue University
                 Fort Wayne

Typical processes
 Batch job
   Perhaps a background application
 Interactive process
 Operating system function
   Monitor performance
   I/O manager
 Spawned subprocesses
   Children of a parent process

Recall . . .
  A process consists of
    Execution context
  The execution context includes all information the
  operating system needs to manage the process

The execution context includes . . .
 Processor state (hardware PCB)
    Program counter
    Stack pointer
 Execution state (running, ready, blocked)
 Priority and privilege
 Memory pointers
 I/O status information
 Accounting information
Process Control Block (PCB)
 Data structure containing the execution context
 Contains sufficient information to allow the process
 to be interrupted and later resumed
 Created and managed by the operating system
 Allows support for multiple processes

Recall . . .
  Each process has an execution state
        Executing on the processor
        Ready to run
        Waiting in a queue for time on the processor
        Waiting for an event to occur
        Cannot run until the event happens
  See next slide for a chronological scenario

 Process switching
                                  I/O request
              timer interrupts

Process A

Process B

Process C



 Interleaved execution of processes on a single processor

Seven-state process model
 We have seen that a process may be
 A typical state transition model includes four
 additional states
Seven-state process model

                   Note: all states
                   but New have an
                   implicit transition
                   to Exit

Additonal states
   The process control block of the new process has been
   The process has not yet been admitted to the pool of
   executable processes
           Perhaps sufficient resources do not yet exist
   The process has been released from the pool of
   executable processes
   Process information is available for performance
   analysis, accounting, or other clean up
Additonal states
 Ready / Suspended
   A ready process is completely swapped out to
   secondary memory
   The process is inactive while in this state
 Blocked / Suspended
   A blocked process is completely swapped out to
   secondary memory waiting for an event
   Event completion moves the process to the
   Ready/Suspended state

Reasons to suspend a process
 To free memory for the remaining processes to use
   This might be done to reduce the virtual memory page
   fault rate
 A utility process may not be needed for a while
   Perhaps only executed periodically
 User request or parent process request
 Lack of use
 Deadlock among processes
Reasons to terminate a process

Reasons to terminate a process

Implementation of Running, Ready, and Blocked states

 In a large operating system, there may be hundreds
 of processes in the blocked state
 It is more efficient to have one blocked queue for
 each event
   Queue holds all processes associated with that event
   Avoids the need to search for processes to release
   whenever an event occurs
 Occurrence of the event releases all processes in
 the associated queue
 If processes have priorities, there would be one
 ready queue for each priority level
 OS control system structures are needed to hold
 information about the current status of each process
 and resource
 Tables are constructed for each entity the operating
 system manages

Memory tables keep track of . . .
 Main memory allocated to the OS and the various
 Secondary memory allocated to each process
 Any allocated shared memory
   This includes protection attributes for access to shared
   memory regions
 Information needed to manage virtual memory
   In paged virtual memory, this includes the page tables
   of the various processes

I/O tables
 Availability of each I/O device
   Is the device assigned to a process?
   If so, which process is the owner?
 Status of I/O operations
   What is the location in main memory being used as the
   source or destination of the I/O transfer?
   Which process is associated with the I/O operation?

File tables
 File tables provide information about . . .
   Existence of files
   Location on secondary memory
   Current status
        Closed or open
        If open, by which process?
 Sometimes this information is maintained by a file
 management system

Process table
 Maintains the process image data structure for
 each process
 The process image includes . . .
   User data
   User activity (program)
   System stack (more user data)
       Local variables
       Parameters
   Process control block (PCB)

Operating system control tables

Process control block
 The process control block was discussed earlier in
 simplified form
 In more detail, the elements of the PCB are . . .
    Process identifiers
    Processor state information (hardware PCB)
        User-visible registers
        Control and status registers
        Stack pointers
    Process control information
        Scheduling and state information
        Related processes
        Interprocess communication information
        Process privileges
        Memory management information
        Resource ownership and utilization
Process identifiers
 Identifiers that may be stored with the process
 control block include
   Internal identifier of this process
   Identifier of the process that created this process
   (parent process)
   User identifier

Processor state info (hardware PCB)
 User-visible registers
 Control and status registers
    Program counter (PC)
    Process status word (PSW) containing . . .
        Condition codes
           • Result of the most recent arithmetic or logical operation
           • For example: sign, zero, carry, equal, overflow
        Status information such as . . .
           •   Trap enable bits for various traps (overflow, underflow, trace)
           •   Interrupt priority level
           •   Execution mode (user, kernel)
           •   Interrupt enable / disable bit

 Stack pointer (SP)
    Possibly one SP for each execution mode
Process control information
   Scheduling and state information
       Process execution state
          • Running, ready, blocked, ready/suspended, etc.
       Priority relative to other processes
       Scheduling-related information
          • The details are specific to each scheduling algorithm used
          • For example, the length of time that the process has been waiting
       Events
          • Identification of the events that must occur before the process can be

Process control information
 Related processes
     A process may be linked to other processes in a queue, ring, etc.
     A process may exhibit a parent-child (creator-created) relationship
      with another process
     The process control block may contain pointers to other
      processes that support these relationships
 Interprocess communication (IPC) information
     Various flags, signals, and messages may be associated with
      communication between two separate processes
     Some or all of this information may be maintained in the process
      control block

Process control information
 Process privileges
     Memory that may be accessed
     The types of instructions that may be executed
     Allowed system utilities and services
 Memory management information
     References to segment and/or page tables that describe the
      virtual memory assigned to this process
 Resource ownership and utilization
     Open files
     Devices currently controlled
     History of utilization of the processor or other resources
        • This may be needed by the scheduler

Execution modes
 Systems typically have two execution modes
   User mode
       Less-privileged mode
       User programs typically execute in this mode
   Kernel mode
       More-privileged mode
       Kernel of the operating system executes in this mode
       Also called system mode or control mode

Execution modes
A user-mode process may run in kernel mode when
The way this is possible is summarized below
   The user-mode process executes a change-mode instruction
       This a special supervisor call instruction
   The change-mode instruction has an integer operand indicating a
   specific OS supervisor routine to be activated
   The supervisor routine runs in kernel mode
       For example, it may control a device
   When done, the supervisor routine executes a special return
   instruction that changes the processor mode back to user mode
In this way, a user-mode process may temporarily gain
necessary privilege in a controlled manner
Mode switch
 An interrupt or supervisor call typically results in a mode
 switch to the interrupt handler or supervisor routine
    Also called a context switch
 A mode switch is typically hardware implemented
    Efficient to perform
    Easy to restore the old mode (context)
 The running process does not undergo a change of state
 from Running to Ready as a result of a mode switch

Mode switch
 What is involved
   The hardware context (hardware PCB) of the
   interrupted process is saved
   The hardware PCB is loaded with a new context
   associated with the appropriate interrupt handler or
   supervisor call

Typical causes for a mode switch
 Clock interrupt
    The process has executed for the maximum allowable time slice
 I/O interrupt
 Memory fault (or page fault)
    There is a reference to a page in virtual memory that has not
    been loaded into main memory
    Error or exception occurred
    This may cause process to be moved to the Exit state
 Supervisor call
    For example, to open a file

Process switch
In contrast to a mode switch, during a process
switch the running process does undergo a
change of state
  Running to Ready
  Running to Blocked
A process switch is performed by operating
system software

Process switch
 What is involved
    A mode switch is performed to an interrupt handler or supervisor
    The handler/routine updates software PCB of running process
    Running process is moved to appropriate queue for its new state
        Ready, Blocked, Ready/Suspended, etc.
    A new process is selected to run next
    The software PCB for the new process is updated
    The new process is removed from its queue (typically Ready)
    Memory-management data structures are updated if needed
    A mode switch is performed from interrupt handler or supervisor
    routine to the new process

Relationship of the OS to processes
 Is the OS kernel a process?
    Non-process kernel
        The OS kernel operates outside of every process
        Operating system code is executed as a separate entity that operates in
         kernel mode
    Execution within user processes
        Except for process switching activity, the OS kernel executes in the
         context of the current user process
        The OS code is in an shared area of virtual memory accessible to all
        Supervisor call overhead is just two mode switches
           • Not two process switches
    Process-based operating system
        Except for process switching activity, the OS is a collection of processes
        Cleaner architecture in a multiprocessor or multicomputer system
UNIX SVR4 process management
 Most of the operating system executes within the
 environment of a user process

UNIX process states

UNIX process states
 The states “Preempted” and “Ready to run in
 memory” are really the same (same queue)
   Reason for dotted line
 Preemption can only occur when a process is about
 to move from kernel mode to user mode
   Perhaps a higher priority process has become ready
 While a process is running in kernel mode, it may
 not be preempted
   This makes UNIX in this form unsuitable for real-time

UNIX process states


To top