CS134a: Processes

1. CS134a: Processes • Processes and concurrent programming • Processes • Process primitives • Synchronization and communication Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014

2. Common System Components • Process Management • Main Memory Management • Secondary-Storage Management • I/O System Management • File Management • Protection System • Networking • Command-Interpreter System Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014

3. What is a process? • An “activity resulting resulting from the execution of a program, with data, by a processor.’’ • Conceptually, each process has its own: • Processor • Program stored in memory • Program state: registers, memory, PC, environment, … (what else?) Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014

4. Process model • The OS is a collection of concurrent processes • Processes operate almost independently of one another • Processes cooperate with messages and signals • Processes compete for resources • The kernel “virtualizes” the CPU (provides the illusion that each process has its own CPU) • What about multiple-CPU machines? Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014

5. Why processes? • A logical construction to cope with complexity • Components in a complex system must have • Well-defined functionality • Well-defined interfaces • Operating systems are reactive systems • The system reacts to events (timers, I/O, faults, etc) • Events occur at unpredictable times and with varying frequency Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014

6. Process flow graphs Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014

7. Example process flow Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014

8. Language • Sequential execution: (P1; P2) • Parallel execution:cobegin P1 | P2 | … | Pn coend • Example:cobegin r1 = a * b | r2 = c / dcoend;r3 = r1 + r2 Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014

9. Fork/Join (Conway 1963, Dennis, Van Horn 1966) • Instructions are labeled • fork l:starts a new process at locationl • joint, l: decrements t, jump to l if t = 0 • (t--; if t = 0 then gotol) // atomic • quit: terminates process • private: declares a variable private to a process Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014

10. Example: image processing • Apply kernel to (n x n) bitmap /* Fork n^2 processes */int m = n * n;private int i, j;for(i = 0; i != n; i++) { for(j = 0; j != n; j++)fork e; };quit; /* Compute a pixel and terminate */e: image[i][j] = kernel(image, i, j);join m, r;quit;r: Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014

11. Unix • fork(): creates two identical processes except: • returns child process number to parent • returns 0 to child • waitpid(pid): block until child number pid finishes • execve(filename, argv, arge):overlay the current process with a new process initialized from program filename, with initial arguments argv, and initial environment arge--in the current directory, with current files, permissions, user, etc. • (Check out /proc filesystem on Linux: contains memory image, files, arguments, cpu time, etc.) Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014

12. Process synchronization • What is the value of x after this computation?int x = 0;cobegin x = x + 1 | x = x + 1coend Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014

13. Atomicity • Atomicity: an operation is atomic if it is always executed without any intervening instructions • Another definition: if the result of an execution is always the result of a possible execution in isolation. • Assumptions: • Reading and writing memory is atomic. Simultaneous operations are serialized in some order. • The relative speeds of processes are unknown. Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014

14. Critical sections • A critical section is a region that is an atomic operation. • At most one process is allowed to be in a critical section at any given time. Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014

15. Software solution (Dijkstra, 1968) • A process not waiting at or within a critical section cannot prevent another process from entering. • Liveness (or “starvation”), if a process is waiting to enter a critical section, another process may not enter infinitely often. • Liveness: two processes must not debate indefinitely when entering a critical section (“after you,” “no, after you”). Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014

16. Attempt #1 • The “turn” variable decides whose turn it is Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014

17. Attempt #2 • Introduce flags for execution in the critical section Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014

18. Attempt #3 • Reset the opposing flag at wait Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014

19. Peterson’s algorithm • Use both turn and critical section flags Computing Systems http://mojave.caltech.edu/cs134/a September 2, 2014