COMP 3430 Robert Guderian

Transcription

1 Operating Systems COMP 3430 Robert Guderian file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 1/53 1

2 Processes file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 2/53 2

3 Textbook references Chapter 4, 13 file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 3/53 3

4 What are they You've used them in a simple way You've made and run programs file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 4/53 4

5 Process vs Program A process is an instance of a program. The same program can be run many times (even at the same time) Each instance is a different process file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 5/53 5

6 Processes and the OS The OS has to track all the processes that are running Tracks: Resources Threads State file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 6/53 6

7 Time-sharing OSes run multiple processes "at the same time" Not really Processes share time on the CPU More on this in scheduling (some spoilers within) file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 7/53 7

8 Process life cycle New -> waiting -> running -> (repeat) -> complete Waiting processes New process CPU Finished Dispatcher Incomplete: to back of the queue file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 8/53 8

9 New process Allocate space Data structures for it (much more later) Program code loaded file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 9/53 9

10 Running Running is also a state machine, job is dispatched (via the dispatcher) Start in READY/WAIT state OS does scheduling (next week...) to put it into RUN BLOCKED - waiting for some event This process gets some time on CPU Go back to READY/WAIT or... file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 10/53 10

11 Complete Clean up resources. Deallocate memory Remove from all queues file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 11/53 11

12 Processes flowing through the system Obviously OSes run more than one process 1 process per processor (hyperthreading not withstanding) We need a queue of waiting processes processes are in "READY" state file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 12/53 12

13 Visualized Recap: Waiting processes New process CPU Finished Dispatcher Incomplete: to back of the queue file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 13/53 13

14 I/O Not a smart use of CPU time What if a process is waiting for an event? CPU has better things to do Processes that are not blocked should run Goes into a BLOCKED state Returns to the READY queue when block clears file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 14/53 14

15 Flow file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 15/53

16 Arpaci-Dusseau file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 16/53 15

17 There's got to be a better way file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 17/53 16

18 Add more queues! Events exiting the CPU (running state) can go to many places If not blocked, back to "READY" queue If blocked, goes to an event queue One event queue per event type When exiting event queue, the process goes to READY queue This turns into a scheduling problem (more later!) file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 18/53 17

19 What if all processes are blocked? What does the processor do? System idle process! Basically avoids a null pointer exception-like error file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 19/53 18

20 You may have seen it... file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 20/53 19

21 More complete view of process states: file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 21/53 20

22 Back to processes More on scheduling later What does a process look like in an OS? What to processes need to function? file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 22/53 21

23 The OS Tracks all: All processes The memory allocated to each (segregation/isolation) I/O for each process Files open for each process Table for each piece of data file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 23/53 22

24 Process image What does a process look like to an OS? Keeps track of the resources. A data structure that is a an abstraction of a process! file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 24/53 23

25 What it looks like PCB Stack \ (\downarrow\) Heap \ (\uparrow\) Static data Code file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 25/53 24

26 What it looks like file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 26/53

27 Process image via Peter Graham 7/11/2018 Operating Systems file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 27/53 25

28 The PCB Holds all the metadata for the process: 1. Process ID 2. Parent Process ID 3. Owner 4. Process state information State, priority, open files Registers 5. Memory allocated file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 28/53 26

29 The /proc filesystem Linux (but not Mac OS) has process information in /proc. See man proc. Notable: /proc/(pid)/exe - symlink to the executing code /proc/(pid)/fd/ - folder that has entries for file descriptors /proc/(pid)/map - mapped memory addresses file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 29/53 27

30 The /proc filesystem More notable: Anything oom means out-of-memory /proc/(pid)/stat - status of the process /proc/(pid)/status - more human-readable version file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 30/53 28

31 ps ps exposes some of this to us ps axo stat,euid,ruid,tty,tpgid,sess,pgrp,ppid,pid,pcpu,comm file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 31/53 29

32 Mode switching PCB maintains state user vs kernel mode file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 32/53 30

33 Kernel mode Can run privileged code in the operating system System calls, signals, interrupts Access devices file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 33/53 31

34 User mode The normal execution Restricted to memory space of this process Data processing, computation file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 34/53 32

35 Mode switching is cheap Toggle a bit in the PCB That's it! file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 35/53 33

36 Context switching Moving to a different process in the CPU PCB Maintains state as it goes in and out of RUN state Save registers, spot of execution (instruction pointer) Move current into a wait queue, run next task Unpack the PCB from next process, dispatch file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 36/53 34

37 Context switching is expensive But it happens all the time Required switching to run multiple programs on a processor file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 37/53 35

38 Processes - how to We fork processes Why: because everything is graph theory! file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 38/53 36

39 Process parent/child relationship Consider: #include <stdio.h> #include <unistd.h> int main() { printf("pid=%d parent=%d\n",getpid(),getppid()); } Run it a bunch of times, who is always your parent? Tip: ps file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 39/53 37

40 About fork What does it return? man fork... file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 40/53 38

41 About fork We now have 2 processes, so the code... forks... into two different places! 0 if you are in the child process The child process ID if you're in the parent process file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 41/53 39

42 Attack of the clones The two processes have the same: memory contents open files register values Different PIDs and OS data structures file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 42/53 40

43 Fork, visualized file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 43/53 41

44 ps,, again Try: ps axo stat,ppid,pid,pcpu,comm file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 44/53 42

45 unistd.h functions for processes exec - execute an external program man 3 exec - a few different options Open Group specifications wait - wait for completion of other processes file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 45/53 43

46 About exec Runs code that is external from this codebase Keeps the same PID, does not start a new process file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 46/53 44

47 UNIX System Initialization fork at every step. We can see this from ps Bootstrap -> swapper swapper forks init systemd forks terminal instances (getty) getty does login, gives us a shell (bash, sh,...) sh forks processes for commands we run file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 47/53 45

48 Kernel design The kernel does the scheduling/process switching/resource handling for us A few different designs file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 48/53 46

49 1. Separate kernel OS maintains its own memory and stack When a process stops: switch modes (cheap) Save state OS executes - prepare next process Switch to new process (context switch) file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 49/53 47

50 2. Execution within user process Process maintains 2 stacks (user and kernel) OS code lives in user address space When control goes to OS, do mode switch Execution stays in process! When OS finishes, return to user process (mode switch) file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 50/53 48

51 3. Process-based OS Major kernel tasks run in processes alongside other processes Modular design, run any kernel processes Smart for multi-core file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 51/53 49

52 In reality: Unix is a mix of 2 and 3 Can do mode switches within processes Has Kernel/OS tasks running alongside our tasks file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 52/53 50

53 References Code examples Linux PCB aka task_struct Linux PID In-class examples file:///users/robg/dropbox/teaching/ /slides/03_processes/index.html?print-pdf#/ 53/53 51