Skip to main content

Source: Operating Systems: Three Easy Pieces (OSTEP) — Chapter 6, Arpaci-Dusseau & Arpaci-Dusseau

Mechanism: Limited Direct Execution

To virtualize the CPU the OS must time-share it — run one process awhile, then another. Two constraints collide:

GoalFear
PerformanceEmulating every instruction would be too slow
ControlA process must not run forever or touch forbidden resources

Crux: how to virtualize the CPU efficiently while the OS keeps control?

Answer: limited direct execution (LDE) — run the program directly on the hardware CPU, but with hardware + OS limits so the kernel stays in charge.

Direct execution (no limits yet)​

Without limits the protocol is almost a library call:

  1. Create process entry, allocate memory, load code
  2. Jump to main()
  3. Process returns → OS frees resources

Fast — but two problems remain:

  1. How does a process do restricted work (I/O, …) without owning the machine?
  2. How does the OS stop a running process to switch to another?

Without limits, the OS is “just a library.”

Problem 1: restricted operations​

User mode vs kernel mode​

ModeWhoPower
UserAppsRestricted — illegal I/O → exception (often kill the process)
KernelOSFull privileges — I/O, timers, trap-table install, …

System calls = controlled entry​

User code requests services via system calls (open, read, fork, …). Under the hood:

  1. C library places syscall number + args in agreed registers/stack
  2. Executes a trap instruction
  3. Hardware: save regs → kernel stack, raise privilege, jump to OS handler from the trap table
  4. OS validates args (never trust user pointers), does the work
  5. return-from-trap → user mode, resume after the trap

User code must not pick an arbitrary kernel address — only a syscall number. The trap table is installed at boot (privileged).

Quiz

Rank the sequence

1 / 1

Order the steps of a system call, from user code to resuming after the trap.

OrderDrag the handle to rearrange — top should be first.

  1. 1OS validates arguments and performs the requested work
  2. 2Executes a trap instruction
  3. 3return-from-trap restores user mode and resumes after the trap
  4. 4Hardware saves registers to the kernel stack, raises privilege, jumps to the trap-table handler
  5. 5C library places the syscall number and arguments in agreed registers/stack

Drag items into the correct order (or use ↑↓), then check.

Protected control transfer

Hardware provides modes + trap / return-from-trap + a place to register handlers. That is how speed and safety coexist.

Problem 2: switching processes​

If a process is on the CPU, the OS is not. So how can the OS decide to switch?

Cooperative approach​

Trust processes to give the CPU back via syscalls (or a yield), or when they fault. Early Mac OS / Xerox Alto style.

Failure mode: infinite loop with no syscall → only fix is often a reboot.

Non-cooperative: timer interrupt​

At boot the OS:

  1. Registers a timer interrupt handler
  2. Starts a hardware timer (privileged)

Every few ms the timer fires → hardware saves state → OS runs. Now the kernel can preempt, schedule, and context switch.

Context switch (idea)​

When the scheduler picks another process:

  1. Hardware already saved user regs of the interrupted process (on its kernel stack)
  2. OS saves kernel regs into that process’s PCB; restores the next process’s; switches kernel stacks
  3. return-from-trap resumes the other process

Two save/restore layers: hardware (user → kernel) and software (process A ↔ B).

Quiz

Rank the sequence

1 / 1

Order the events of a timer-driven context switch from process A to process B.

OrderDrag the handle to rearrange — top should be first.

  1. 1Hardware saves the interrupted process A's user registers onto its kernel stack
  2. 2return-from-trap resumes execution, but now as process B
  3. 3OS saves kernel registers into A's PCB, restores B's, and switches kernel stacks

Drag items into the correct order (or use ↑↓), then check.

Interactive: LDE protocols​

Try:

  • Boot + LDE — trap table + timer, then user-mode process
  • System call — trap, validate, return-from-trap
  • Timer + switch — preempt A, context-switch to B

Check your understanding​

Quiz

Limited direct execution

1 / 4

Limited direct execution primarily means…

Pick an answer to see if you are right.

Coding challenges​

Conceptual drills in Python (no traps in Piston). The measurement homework below is still C on your machine.

Homework lab: measure syscall & context-switch cost​

Measurement homework (OSTEP): time a null system call and estimate a context switch on a real UNIX-like machine. Notes/screenshots stay in this browser.

Lab

Homework: measure syscall & context switch

0/5 started

Loading lab…

Concurrency teaser​

What if a timer fires during a syscall? Or one interrupt during another? The OS must protect itself (e.g. briefly disable interrupts, locks). Full story: concurrency chapters later.

Summary​

TermMeaning
Limited direct executionRun natively, with limits
User / kernel modeRestricted vs privileged
Trap / return-from-trapEnter / leave the kernel safely
Trap tableBoot-time map of handlers
System callRequest a numbered kernel service
Timer interruptPreempt without cooperation
Context switchSave one process, restore another

Next: Scheduling Introduction — FIFO, SJF, STCF, Round Robin — then Multi-Level Feedback Queue.

Further Reading​