Lecture 2 - Processes
eecs-482
Overview
Complexity
- operating systems became complex to more efficiently use the hardware they run on
- multiple users, programs, I/O devices
- originally for efficient use of hardware, but useful even now
Abstraction
- separate applications into several independent tasks, where each one gets its own virtual CPUs and memory, and has the understanding that it has unrestricted access to resources
Process
- formal: one or more threads in an address space
- informal: a program in execution
- process != program
- analogy: a play being acted out
- a program is the script of the play
Thread
- a sequence of executing instructions
- active
- analogy: a role in the play
Address Space
- the memory data used by the threads
- passive: acted on by the threads
- analogy: the props on the stage
Per-Thread State vs Shared State
- per-thread state:
- code + code pointer (program counter)
- stack + stack pointer
- shared state:
- data segment (heap + static variables)
Why Threads?
Scenario
- single-processor web server
- receives multiple simultaneous requests
- reads web pages from disk to satisfy each request
Option 1: Handle one request at a time
- pros: easy to program
- cons: slow; can only handle one task at a time (receive requests, fetch page from disk)
Option 2: Asyncio
- issue I/Os, but don’t wait for them to complete
- pros: fast
- cons: hard to program
- extra states to remember (what reqs are being served and their states, what disk I/Os are outstanding, which requests they belong to)
Option 3: Multi-threaded web server
- one thread per request
- thread issues disk/network IO, then waits for it to finish
- threads are not blocked by one another
- basically best of both worlds