UC Berkeley CS162 Operating Systems Lecture 2 - Introduction to Processes

Course Link(including Slides and Materials)

Online Video Link

Four Fundamental OS Concepts


  • Single unique execution context: fully describes program state
  • Program Counter, Registers, Execution Flags, Stack

Address space (with translation)

  • Programs execute in an address space that is distinct from the memory space of the physical machine


  • An instance of an executing program is a process consisting of an address space and one or more threads of control

Dual mode operation / Protection

  • Only the “system” has the ability to access certain resources
  • The OS and the hardware are protected from user programs and user programs are isolated from one another by controlling the translation from program virtual addresses to machine physical addresses

OS Bottom Line: Run Programs

  • Load instruction and data segments of executable file into memory
  • Create stack and heap
  • “Transfer control to program”
  • Provide services to program
  • While protecting OS and program

What happens during program execution?

  • Execution sequence:
    • Fetch Instruction at PC
    • Decode
    • Execute (possibly using registers)
    • Write results to registers/mem
    • PC = Next Instruction(PC)
    • Repeat

First OS Concept: Thread of Control

  • Certain registers hold the context of thread

    • Stack pointer holds the address of the top of stack
      • Other conventions: Frame pointer, Heap pointer, Data
    • May be defined by the instruction set architecture or by compiler conventions
  • Thread: Single unique execution context

    • Program Counter, Registers, Execution Flags, Stack
  • A thread is executing on a processor when it is resident in the processor registers.

  • PC register holds the address of executing instruction in the thread

  • Registers hold the root state of the thread.

    • The rest is “in memory”

Second OS Concept: Program’s Address Space

  • Address space $\Rightarrow$ the set of accessible addresses + state associated with them:

    • For a 32-bit processor there are 232 = 4 billion addresses
  • What happens when you read or write to an address?

    • Perhaps nothing
    • Perhaps acts like regular memory
    • Perhaps ignores writes
    • Perhaps causes I/O operation
      • (Memory-mapped I/O)
    • Perhaps causes exception (fault)

How can we give the illusion of multiple processors?


  • Assume a single processor. How do we provide the illusion of multiple processors?

    • Multiplex in time!
  • Each virtual “CPU” needs a structure to hold:

    • Program Counter (PC), Stack Pointer (SP)
    • Registers (Integer, Floating point, others…?)
  • How switch from one virtual CPU to the next?

    • Save PC, SP, and registers in current state block
    • Load PC, SP, and registers from new state block
  • What triggers switch?

    • Timer, voluntary yield, I/O, other things

The Basic Problem of Concurrency

  • The basic problem of concurrency involves resources:

    • Hardware: single CPU, single DRAM, single I/O devices
    • Multiprogramming API: processes think they have exclusive access to shared resources
  • OS has to coordinate all activity

    • Multiple processes, I/O interrupts, …
    • How can it keep all these things straight?
  • Basic Idea: Use Virtual Machine abstraction

    • Simple machine abstraction for processes
    • Multiplex these abstract machines
  • Dijkstra did this for the “THE system”

    • Few thousand lines vs 1 million lines in OS 360 (1K bugs)

Properties of this simple multiprogramming technique

  • All virtual CPUs share same non-CPU resources

    • I/O devices the same
    • Memory the same
  • Consequence of sharing:

    • Each thread can access the data of every other thread (good for sharing, bad for protection)
    • Threads can share instructions
      (good for sharing, bad for protection)
    • Can threads overwrite OS functions?
  • This (unprotected) model is common in:

    • Embedded applications
    • Windows 3.1/Early Macintosh (switch only with yield)
    • Windows 95—ME (switch with both yield and timer)


  • Operating System must protect itself from user programs

    • Reliability: compromising the operating system generally causes it to crash
    • Security: limit the scope of what processes can do
    • Privacy: limit each process to the data it is permitted to access
    • Fairness: each should be limited to its appropriate share of system resources (CPU time, memory, I/O, etc)
  • It must protect User programs from one another

  • Primary Mechanism: limit the translation from program address space to physical memory space

    • Can only touch what is mapped into process address space
  • Additional Mechanisms:

    • Privileged instructions, in/out instructions, special registers
    • syscall processing, subsystem implementation
      • (e.g., file access rights, etc)

Third OS Concept: Process

  • Process: execution environment with Restricted Rights

    • Address Space with One or More Threads
    • Owns memory (address space)
    • Owns file descriptors, file system context, …
    • Encapsulate one or more threads sharing process resources
  • Why processes?

    • Protected from each other!
    • OS Protected from them
    • Processes provides memory protection
    • Threads more efficient than processes (later)
  • Fundamental tradeoff between protection and efficiency

  • Communication easier within a process

  • Communication harder between processes

  • Application instance consists of one or more processes


  • Threads encapsulate concurrency: “Active” component

  • Address spaces encapsulate protection: “Passive” part

    • Keeps buggy program from trashing the system

Fourth OS Concept: Dual Mode Operation

  • Hardware provides at least two modes:

    • “Kernel” mode (or “supervisor” or “protected”)
    • “User” mode: Normal programs executed
  • What is needed in the hardware to support “dual mode” operation?

    • A bit of state (user/system mode bit)
    • Certain operations / actions only permitted in system/kernel mode
      • In user mode they fail or trap
    • User à Kernel transition sets system mode AND saves the user PC
      • Operating system code carefully puts aside user state then performs the necessary operations
    • Kernel à User transition clears system mode AND restores appropriate user PC
      • return-from-interrupt


Process Control Block

  • Kernel represents each process as a process control block (PCB)

    • Status (running, ready, blocked, …)
    • Register state (when not ready)
    • Process ID (PID), User, Executable, Priority, …
    • Execution time, …
    • Memory space, translation, …
  • Kernel Scheduler maintains a data structure containing the PCBs

  • Scheduling algorithm selects the next one to run