COP 3402 meeting -*- Outline -*-

* Processes
   Based on chapter 9 of Systems Software by Montagne
   and Operating Systems: Three Easy Pieces
   by Arpaci-Dusseau and Arpaci-Dusseau
     (see https://pages.cs.wisc.edu/~remzi/OSTEP/)

** What is a process?
      (term from design of CTSS in 1962)
      
------------------------------------------
            PROCESS

def: a *process* in an OS is


A process is also called a *task*

OS Goal:



Characteristics:






------------------------------------------
        ... a program being run (or that could be run)
              (i.e., a program that has been loaded)
            "an activity or series of activities" being carried out

        ... give illusion that the process has the whole computer to itself
               (by default,
                although it might need to wait sometimes,
                and some processes need to cooperate with others)

        ... - is active (running or waiting to run)
            - has its own memory
                (address space, including runtime stack, registers,
                 heap, files, etc.)
            - has various permissions
                (usually inherited from the user that started it)

------------------------------------------
         PROGRAM VS. PROCESS

Is a program a process and vice versa?





How does a program become a process?



------------------------------------------

        ... No:
           - a program is not executing,
           - a program is represented by an object file

        ... by loading the program,
            allocating a PCB and PAS,
            and dispatching to the process (running it)

*** Process Control Block (PCB)
------------------------------------------
      PROCESS CONTROL BLOCK (PCB)

def: a *process control block (PCB)* is





Typical information in a PCB:












------------------------------------------

        ... a data structure (a record/struct)
            that an OS uses to manage processes
            (also called a "process descriptor" or "context")

        ... - process ID (or name)
            - mode (user or system)          "static info."
            - priority (for scheduling)
            - state (running, waiting, etc.) "dynamic info."
            - code or pointers to the code     "address space info."
            - BP and SP of runtime stack
            - PC and other registers
            - files open
            - etc. (depends on OS)

        Q: Why put the BP, SP, and PC into the PCB?
           If we need to stop the process, need this information
           recorded, so can restart it

*** Process Address Space
------------------------------------------
        PROCESS ADDRESS SPACE

def: a *process address space* is




Layout (in Unix):

     |-------------------|
     |      Stack        |
     |        |          |
     |        v          |
     |                   |
     |                   |
     |-------------------|
     |                   |
     |        ^          |
     |        |          |
     |      Heap         |
     |-------------------|
     |                   |
     |      Data         |
     |                   |
     |-------------------|
     |                   |
     |      Text         |
     |                   |
     |-------------------|

------------------------------------------
        ... a area of memory
            assigned by the OS to a process

        The text (code) segment starts at address 0
        The data segment stores global variables (and constants)
        The heap is what malloc manipulates, it grows up
        The stack is used by call and return instructions,
            it actually grows down (towards the heap)

*** Process States
------------------------------------------
         PROCESS STATE

def: a *process state* represents the


Examples:

 Ready:

 Running:

 Waiting:

 Suspended:

 End:

 Abend: 
------------------------------------------
        ... activity that the process is doing

        ...
          Ready: waiting to run on the CPU
          Running: using the CPU
          Waiting: waiting for I/O to finish
          Suspended: temporarily waiting for the OS
          End: finished execution
          Abend: finished due to error or violating a policy

*** Events
------------------------------------------
     AN OS AS AN EVENT-DRIVEN PROGRAM

                            [Suspended]
                            ^        /
                 dispatch   |stop   resume
  create         /-----\    |      v
    *---> [Ready]      |--> [Running]
            ^   ^         /  |   || EOP
            |   \---------   /   | \->[End]
         I/O|       timer   /SIO |
      interrupt            /     |trap
             \--[Waiting]-/      v
                              [Abend]
        
------------------------------------------

        Events (interrupts) cause transitions from one state to another

        So an OS is an event-driven system

        Q: Why would the OS need to stop a running program?
           To handle an I/O interrupt, or other asynchronous event