Midterm Review. CSE 120: Principles of Opera=ng Systems. UC San Diego: Summer Session I, 2009 Frank Uyeda

Transcription

1 Midterm Review CSE 120: Principles of Opera=ng Systems UC San Diego: Summer Session I, 2009 Frank Uyeda

2 Course Content Role of an Opera=ng System Concurrency and Synchroniza=on What are the challenges to support mul=tasking? Midterm CPU Scheduling Who gets the CPU and when do they get it? Memory Management How do programs share finite memory? File Systems and Storage Management How is data stored and what happens when things fail? Selec=on of Special Topics (=me permipng) Security, Virtual Machine Monitors,.. 2

3 Computer Organiza=on Monitor Scanner Keyboard Printer Disk drive CPU Video controller USB controller Disk controller System bus Memory 3

4 What is an Opera=ng System? Abstrac=ons to ease applica=on development Manage resource access among applica=ons Applica=ons VM Opera=ng Systems ) Hardware 4

5 Types of Hardware Support Protec=on OS wants to control hardware access OS wants to keep par=cular data (registers, memory) private and isolated Event handling OS needs to be aware of external events OS needs a way to respond to external events Performance improvements Commonly used thread synchroniza=on primi=ves Memory access / Disk access speed ups 5

6 Suppor=ng Privileged Instruc=ons How does an OS or CPU use protec=on levels? There is a special register on the CPU indica=ng the mode CPU checks mode bit when execu=ng privileged instruc=ons User programs execute in user mode OS executes in kernel mode For now, think of the kernel as equivalent to an OS 6

7 Events Two types of events Interrupts: caused by external event Excep=ons: caused by an instruc=on Events can be: Unexpected Deliberate Unexpected Deliberate Excep1on (sync) Fault Syscall trap Interrupt (async) Interrupt Soaware Interrupt 7

8 Handling Interrupts Polling Kernel busy waits for signal Note: textbook uses slightly different defini=on and dis=nguishes it completely from IRQ Can be inefficient depending on frequency Interrupt Handler Interrupt causes processor to trap into kernel Kernel invokes appropriate interrupt handler Interrupt handler saves process state, processes interrupt, restores state and returns 8

9 System Calls Applica=on invokes a system call to execute a privileged opera=on Raises an excep=on, which invokes kernel handler Passes parameters to handler Predefined System Call code, any other arguments Kernel handler does the rest saves caller context (state) calls proper system call rou=ne restores called state and returns 9

10 Concurrency Uniprogramming OS runs a single job un=l it is completed. Mul=programming OS has a queue of jobs Selects one job to run If the job has to wait for I/O or has run for awhile, the OS saves its state and puts it back into the queue. Repeat last 2 steps un=l all jobs complete. 10

11 Process A process is the chosen OS abstrac=on for a job/task Unit of execu=on Unit of scheduling Unit of accoun=ng A process is the instan=a=on of a program All processes are associated with a program A program or applica=on can have mul=ple processes 11

12 What is in a Process? Program Informa=on Address space, Code, Data, Stack, Registers (SP, PC, FP,..) Opera=ng System resources Open files, open network sockets Execu=on state Running: currently using the CPU Ready: ready to use the CPU (wai=ng for it) Another process has CPU Wai=ng: wai=ng for an event (not the CPU) such as I/O Cannot make progress un=l signaled 12

13 Context Switch Two processes: P 0 and P 1 The OS consumes a fair amount of processing =me This =me is referred to as context switching overhead Too much context switching overhead is a bad thing (why?) Note: image courtesy of Silberschatz,

14 Scheduling Queues The OS keeps track of non running processes in scheduling queues Ready queue Firefox PCB X Server PCB Idle PCB head tail Disk I/O PCB head tail Emacs PCB Bash PCB Terminal PCB There may be many wait queues see Nachos.threads.ThreadedQueue 14

15 Process Crea=on in Unix fork() system call is used to create a new process int fork() Creates and ini=alizes a new PCB Creates a new address space Fills child s address space with a copy of the parent s en=re address space Ini=alizes kernel resources to point to parent s Puts PCB on the ready queue So..how do we know which one is which? Each process has a different PID fork() returns twice: child s PID to the parent 0 to the child 15

16 Unix fork() example int main(int argc, char *argv[]) { char *name = argv[0]; int child_pid = fork(); if (child_pid == 0) { printf( Child of %s is %d\n, name, getpid()); return 0; } else { printf( My child is %d\n, child_pid); return 0; { } What does this program print? Note: This example courtesy of Alex Snoeren 16

17 Shared Memory vs. Message Passing Process A Process A Process B hello world (stdout) Process B hello world shared_mem Kernel Physical Memory Kernel Physical Memory 17

18 Interprocess Communica=on Each coopera=ng must know the name of the other Shared Memory Can perform frequent and large transfers Must synchronize Message Passing No explicit need for synchroniza=on Handled by read(), write() syscalls. Kernel overhead per message Other common varia=ons of IPC Unix pipes (e.g., ls wc ) Windows Local Procedure Calls (LPCs) 18

19 Threads Separate the concept of a process from its execu=on state Process: address space, privileges, resources Execu=on state: registers, PC, SP, FP Execu=on state is called a thread of control Each thread belongs to a process Each process has at least one thread Threads are the units of scheduling (sort of) CPU runs one thread at a =me Threads execute within the context of a process 19

20 Thread in a Process Address Space 0xFFF.. (Ending Address) Stack SP1 Heap Data Segment Text Segment PC1 0x00. (Star=ng Address) 20

21 Threads in a Process Address Space SP3 Stack (Thread 3) 0xFFF.. (Ending Address) Stack (Thread 2) SP2 Thread 3 Stack (Thread 1) SP1 Thread 2 Heap Thread 1 Data Segment PC3 Text Segment PC1 PC2 0x00. (Star=ng Address) 21

22 Mul= process Web Server Using fork() for concurrency while (1) { } int sock = accept(); if ((child_pid = fork())== 0) { } Handle client request Close socket and exit else { } Close socket Before Aaer 22

23 Mul= threaded Web Server Using thread_fork() for concurrency while (1) { int sock = accept(); thread_fork(handle_req, sock); } } Before Aaer handle_req(int sock) { } Handle client request close(sock) 23

24 Scheduling Threads Process decides (user level) OS scheduler s=ll schedules per process Threads run in context of current PCB Kernel decides (kernel level) Kernel maintains thread control blocks (TCB). Kernel schedules ready threads to run. 24

25 Non Preemp=ve Scheduling Thread voluntarily gives up the CPU with thread_yield() Ping Thread while (1) { printf( ping\n ); thread_yield(); } Pong Thread while (1) { printf( pong\n ); thread_yield(); } What is the output of running these two threads? 25

26 Preemp=ve Scheduling What s the danger with non preemp=ve threads? A thread can own CPU Only voluntary calls of thread_{yield(), stop() exit()} releases the CPU Preemp=ve scheduling causes involuntary context switch Uses =mer interrupt to force thread_yield() call Nachos uses this technique 26

27 Threads Summary Parallelism useful for many applica=ons Processes are oaen too heavyweight Separa=ng parallel tasks as threads improves efficiency of mul=tasking Two primary types of threads Kernel level threads: can be efficient, but has overhead User level threads: much faster, but not supported well by OS Are there any drawbacks to threads? Difficult to program correctly No longer assume exclusive use of the resources. It s hard to get them to cooperate 27

28 When Are Resources Shared? Local variables are not shared (private) Refer to data on the stack Each thread has its own stack Should never pass/share a pointer to a local variable on the stack for thread T1 to another thread T2 Global variables and sta=c objects are shared Stored in sta=c data segment Accessible by any thread Dynamic objects (heap) are shared Allocated from heap with malloc/free or new/delete 28

29 Threading Assump=ons We assume that the only atomic ac=ons are reads and writes of words Not always the case on some architectures We assume that a context switch can occur at any =me. We assume that you can delay a thread as long as you like as long as it s not delayed forever. 29

30 Classic Example We ll represent the situa=on by crea=ng a thread for each person to do the withdrawals These threads run in the same Bank process withdraw(account, amount) { balance = get_balance(account); balance = balance - amount; put_balance(account, balance); return balance; } withdraw(account, amount) { balance = get_balance(account); balance = balance - amount; put_balance(account, balance); return balance; } What s the problem with this implementa=on? Think about the poten=al sequence of execu=ons for these threads 30

31 Interleaved Schedule The problem is that the execu=on of the two threads can be interleaved: Execu=on sequence seen by CPU balance = get_balance(account); balance = balance amount; balance = get_balance(account); balance = balance - amount; put_balance(account, balance); put_balance(account, balance); Context switch What is the balance of the account? This is known as a race condi=on: The outcome of a computa=on is dependent on the =ming or interleaving of instruc=ons. 31

32 Cri=cal Sec=on Requirements 1. Mutual exclusion If one thread is in the cri=cal sec=on, then no other is 2. Progress If some thread T is not in the cri)cal sec)on, then T cannot prevent some other thread S from entering the cri=cal sec=on 3. Bounded wai=ng (no starva=on) If some thread T is wai=ng on the cri=cal sec=on, then T will eventually enter the cri=cal sec=on 4. No assump=ons on performance Requirements must be met with any number of CPUs with arbitrary rela=ve speeds 32

33 Locks One way to implement cri=cal sec=ons is to lock the door on the way in, and unlock it again on the way out A lock is an object in memory providing two opera=ons acquire(): before entering the cri=cal sec=on release(): aaer leaving a cri=cal sec=on Threads pair calls to acquire() and release() Between acquire()/release(), the thread holds the lock acquire() does not return un=l any previous holder releases 33

34 Peterson s Algorithm Take turns only if somebody else is interested; otherwise just go struct lock { int turn = 0; int interested[2] = [FALSE,FALSE]; } void acquire(lock) { lock->interested[this_thread] = TRUE; turn = other_thread; while (lock->interested[other_thread] && turn == other_thread); } void release(lock) { lock->interested[this_thread] = FALSE; } 34

35 Using Test and Set Here is a simple lock implementa=on with test and set: struct lock { int held = 0; } void acquire(lock) { while (test-and-set(&lock->held)); } void release(lock) { lock->held = 0; } bool test_and_set(bool *flag) { bool old = *flag; *flag = True; return old; } 35

36 Problems with Spin Locks The problem with spinlocks is that they are wasteful If a thread is spinning on a lock, then the thread holding the lock cannot make progress How did the lock holder give up the CPU in the first place? Lock holder calls yield or sleep Involuntary context switch Only want to use spin locks as primi=ves to build higher level synchroniza=on constructs 36

37 Disabling Interrupts Another implementa=on of acquire/release is to disable interrupts: struct lock { int held = 0; } void acquire(lock) { disable interrupts; } void release(lock) { enable interrupts; } Note that there is no state associated with the lock 37

38 Summarize Where We Are Goal: Use mutual exclusion to protect cri=cal sec=ons of that access shared resources Method: Use locks (spin locks or disable interrupts) Problem: Cri=cal sec=ons can be long Spin locks: Threads wai=ng to acquire lock spin in test and set loop Wastes CPU cycles Longer the CS, the longer the spin Greater the chance for lock holder to be interrupted acquire(lock) Cri)cal Sec)on release(lock) Disabling Interrupts: Should not disable interrupts for long periods of =me Can miss or delay important events (e.g., =mer, I/O) 38

39 Higher Level Synchroniza=on Need higher level synchroniza=on primi=ves that: Block waiters Leave interrupts enabled within the cri=cal sec=on All synchroniza=on requires atomicity So we ll use our atomic locks as primi=ves to implement them 39

40 Semaphores Semaphores are another data structure that provides mutual exclusion to cri=cal sec=ons Block waiters, interrupts enabled within cri=cal sec=on Semaphores support two opera=ons: wait(semaphore): block un=l semaphore is open, decrement Blocking threads are put on a wait queue. signal(semaphore): increment, allow another thread to enter If no threads are wai=ng on the queue, the signal is remembered for the next thread In other words, signal() has history Semaphores can also be used as atomic counters 40

41 Semaphore Types Semaphores come in two types Determined by semaphore value (aka count ) Mutex semaphore (count = 1) Represents single access to a resource Guarantees mutual exclusion to a cri=cal sec=on Coun=ng semaphore (count = N) Represents a resource with many units available, or a resource that allows certain kinds of unsynchronized concurrent access (e.g., reading) N threads can pass the semaphore 41

42 Semaphore Summary Semaphore drawbacks They are essen=ally shared global variables Can poten=ally be accessed anywhere in program No connec=on between the semaphore and the data being controlled by the semaphore Used both for cri=cal sec=ons (mutual exclusion) and coordina=on (scheduling) Note that I had to use comments in the code to dis=nguish No control or guarantee of proper usage Some=mes hard to use and prone to bugs Another approach: Use programming language support 42

43 Monitors A monitor is a programming language construct that controls access to shared data Synchroniza=on code added by compiler, enforced at run=me Why is this an advantage? A monitor is a module that encapsulates Shared data structures Procedures that operate on the shared data structures Synchroniza=on between concurrent threads that invoke the procedures A monitor protects its data from unstructured access It guarantees that threads accessing its data through its procedures interact only in legi=mate ways 43

44 Monitor Seman=cs A monitor guarantees mutual exclusion Only one thread can execute any monitor procedure at any =me (the thread is in the monitor ) If a second thread invokes a monitor procedure when a first thread is already execu=ng one, it blocks So the monitor has to have a wait queue If a thread within a monitor blocks, another one can enter 44

45 Condi=on Variables Condi=on variables provide a mechanism to wait for events (a rendezvous point ) Condi=on variables support three opera=ons: Wait: release monitor lock, wait for C/V to be signaled So CVs have wait queues too Signal: wakeup one wai=ng thread Broadcast: wakeup all wai=ng threads 45

46 Hoare vs Mesa Monitors Hoare (immediately switch to wai=ng thread) if (empty) wait(condition) Mesa (put wai=ng thread on ready queue) while(empty) wait(condition) Tradeoffs Mesa monitors easier to use, more efficient Fewer context switches, easy to support broadcast Hoare monitors leave less to chance Easier to reason about the program 46

47 Condi=on Variables and Locks Condi=on variables are also used without monitors in conjunc=on with blocking locks A monitor is just like a module whose state includes a condi=on variable and a lock Difference is syntac=c; with monitors, compiler adds the code It is just as if each procedure in the module calls acquire() on entry and release() on exit But can be done anywhere in procedure, at finer granularity With condi=on variables, the module methods may wait and signal on independent condi=ons 47

48 Using Condi=on Variables and Locks Alterna=on of two threads (ping pong) Each executes the following: Lock lock; Condition cond; void ping() { acquire(lock); while(1) { printf( ping\n ); signal(cond, lock); wait(cond, lock); } release(lock); } Must acquire lock before you can wait (similar to needing interrupts disabled to call sleep in Nachos) Wait atomically releases lock and blocks un=l signal() Wait atomically acquires lock before it returns 48

49 Synchroniza=on Summary Semaphores wait()/signal() implement blocking mutual exclusion Also used as atomic counters (coun=ng semaphores) Can be inconvenient to use Monitors Synchronizes execu=on within procedures that manipulate encapsulated data shared among procedures Only one thread can execute within a monitor at a =me Relies upon high level language support Condi=on variables Used by threads as a synchroniza=on point to wait for events Inside monitors, or outside with locks 49

50 Scheduling Horizons Scheduling works at two levels in an opera=ng system Long term scheduling happens rela=vely infrequently Significant overhead in swapping a process out to disk Short term scheduling happens rela=vely frequently Want to minimize the overhead of scheduling 50

51 Scheduling Goals Scheduling algorithms can have many different goals: CPU u=liza=on I/O u=liza=on Job throughput (# jobs/unit =me) Turnaround =me (T finish T arrival ) Wai=ng =me (Avg(T wait ): avg =me spent on wait queues) Response =me (Avg(T ready ): avg =me spent on ready queue) Batch systems Strive for job throughput, turnaround =me (supercomputers) Interac=ve systems Strive to minimize response =me for interac=ve jobs (PC) 51

52 Starva=on Starva=on occurs when a job cannot make progress because some other job has the resource it requires We ve seen locks, Monitors, Semaphores, etc. The same thing can happen with the CPU! 52

53 Scheduling Algorithms First come first served (FCFS), first in first out (FIFO) Jobs are scheduled in order of arrival to ready queue Shortest Job First (SJF) Choose the job with the smallest expected CPU burst Person with smallest number of items to buy Provably op=mal minimum average wai=ng =me Round Robin Ready queue is treated as a circular queue (FIFO) Each job is given a =me slice called a quantum Priority Scheduling Choose next job based on highest priority 53

54 Combining Algorithms Scheduling algorithms can be combined Have mul=ple queues Use a different algorithm for each queue Move processes among queues Mul=ple Level Feedback Queues (MLFQ) Mul=ple queues represen=ng different job types Interac=ve, CPU bound, batch, system, etc. Queues have priori=es, jobs on same queue scheduled RR Jobs can move among queues based upon execu=on history Feedback: Switch from interac=ve to CPU bound behavior 54

55 Priority Inversion Problem descrip=on A high priority thread is stuck wai=ng for a low priority thread to finish In this case, the medium priority thread was holding up the lowpriority thread Solu=on: Priority Inheritance Allow a thread to inherit the priority of any thread that is wai=ng for it Blocked, higher priority threads donate their priority to lower priority threads Dona=on only occurs as long as the higher priority thread is blocked once this is no longer true, threads retain their original priority 55

56 Deadlock Defini=on Defini=on: Deadlock exists among a set of processes if every process is wai=ng for an event that can be caused only by another process in the set. 56

57 Condi=ons for Deadlock Deadlock can exist if and only if four condi=ons hold: Mutual exclusion At least one resource must be held in a non sharable mode (i.e., only one instance) Hold and wait There must be one process holding one resource and wai=ng for another resource No preemp=on resources cannot be preempted (i.e., cri=cal sec=ons cannot be aborted externally) Circular wait There must exist a set of processes {P 1, P 2, P 3,,P n } such that P 1 is wai=ng for a resource held by P 2, P 2 is wai=ng for P 3,, and P n for P 1 57

58 Dealing with Deadlock There are four ways to deal with deadlock: Ignore it Do you feel lucky? Preven=on Make one of the four condi=ons impossible Avoidance Control alloca=on of resources (Banker s Algorithm) Detec=on and recovery Look for a cycle in dependencies Preempt or abort 58

59 Starva=on: Starva=on and Deadlock A thread never makes progress because other threads are using a resource it needs Deadlock: A circular resource dependency between mul=ple threads such that none of them can make progress. Starva=on is not the same as deadlock 59