Goals. Processes and Threads. Concurrency Issues. Concurrency. Interlacing Processes. Abstracting a Process

Transcription

1 Goals Processes and Threads Process vs. Kernel Thread vs. User Green Threads Thread Cooperation Synchronization Implementing Concurrency Concurrency Uniprogramming: Execute one program at a time EX: MS/DOS, Early Mac Easier to implement, less to worry about Want to execute many applications at the same time (Multiprogramming) Windowing systems do not experience slowdown even if an application is processing data EX: Unix, Linux, Mac OS X, Windows NT/2000/XP Harder to implement All sorts of concurrency issues Concurrency Issues Access to resources CPU, Memory, I/O OS in charge of coordination Abstract the idea of a process and make it seem as though it is executing on a uniprogramming OS Now worry about interlacing these abstractions I/O1 I/O2 P1 P3 CPU P4 P2 MEM I/O3 Abstracting a Process Interlacing Processes What is a process? Execution Memory Registers Instn... Inst6 Inst5 Inst4 Inst3 Inst2 Inst1 Inst0 Execution 1.Fetch at PC 2.Decode 3.Execute 4.Write Results 5.Loop PC P0 P1 P0 P2 P1 Time Interlace with time Remember: Program Counter (PC), pointer, Registers Switching Save current state Load new state When to switch Time, voluntary yield, I/O, other concerns

2 Translation Map Translation Map Protection In the current scheme all processors share: I/O devices Memory Threads can over-ride each other s data Threads can access each other s instructions Protection To protect we need to make sure that: Protect Memory Every process does not have access to all memory Protect I/O Every process does not have access to all I/O Preemptive switching of processes Use of a timer Processes cannot disable the timer Translations Context Switching P1 Map virtual address space to physical address space On a switch load a new translation map P2 OS OS Context Switching Changing processes Context switch overhead sets minimum switching time Idle Save State Reload State Save State Reload State Idle Idle Process State new: process is created ready: process is waiting to run running: instructions are executed waiting: process is waiting for an event terminated: process has finished execution new admitted ready I/O or event completion interrupt scheduler dispatch waiting terminated exit running I/O or event wait Creating a process Process state is held in a process control block (PCB) To make a new process: Construct PCB Set up page tables for address space Copy data from parent process? Copy I/O state (file handles, etc) Is process == program???

3 Translation Map Translation Map Process Collaboration Hight Creation/memory Overhead (Relatively) Hight Context-Switch Overhead Need communication Shared-Memory Message Passing Shared Memory Communicate by reading/writing to the same memory Low overhead Complex synchronization problems P1 Shared P2 Shared Shared Inter-process Communication Kernel Threads Processes send messages through an IPC facility Transfer information without shared variables Works over a network Harder to implement Maybe more overhead Less concurrency problems Sequential execution stream within a process No protection between threads Process still contains a single Address Space Why separate the threads from processes Threads provide concurrency to a process Easy to share data Heavyweight Process = Process with one thread Thread State Thread State State shared by all threads in process/address space Contents of memory (global variables, heap) I/O state (file system, network, etc.) State private to each thread Kept in Thread Control Block (TCB) CPU registers (including PC) Execution Parameters, temporary variables return PCs Each thread has a Thread Control Block (TCB) Execution State Scheduling info Accounting info etc... OS keeps track of TCBs in protected memory

4 Thread Queues When thread is not running, its TCB is in a scheduler queue Separate queues for each device/ signal/condition Each queue can have different scheduling policy Ready Head Tail Disc Head Tail Ether Head Tail TC TC TC NULL NULL TC OS Dispatch Loop Loop { RunThread(); ChooseNextThread(); SaveStateOfCPU(curTCP); LoadStateOfCPU(newTCP); Running a Thread Creating a Thread How to run a thread Load its state Load the environment Jump to the PC How does the dispatcher get control (next week) Internal events: thread returns control voluntarily External events: thread gets preempted Need information: Pass a function pointer to application routine Pointer to array of arguments Size of the stack to allocate Implementation Check all arguments Allocated new and TCB Initialize TCB and place in ready queue How to initialize Initialize register fields of TCB pointer points at the stack PC address => OS routine ThreadRoot() Two arg registers initialized to function and arguments Starting a Thread Eventually the dispatcher will select this TCB and begin in ThreadRoot() ThreadRoot Do Housekeeping Switch to user mode Call threaded code Finish the thread starts at user-level ThreadRoot Threaded run thread switch ThreadRoot

5 Thread Finish Join System Call Needs to re-enter kernel mode Wake up threads waiting for this thread Can t deallocate thread yet We are running on its stack Instead mark thread as to be destroyed Thread Housekeeping on another thread will deallocate One thread can wait for another to finish Calling thread is taken off the run queue and placed on the waiting queue for the thread it is waiting for Where to store this queue? TCB for the thread to join on Kernel vs. User-Mode Threading Models Kernel threads Native threads supported by the kernel Every thread is independent One process can have multiple threads Problems with Kernel threads Need to cross into kernel mode to schedule Lighter Option: User threads User program provides threading and scheduling Multiple threads per kernel thread May schedule non-preemptively Cheap Downsize to User threads When one thread blocks, all block Kernel cannot adjust scheduling K K K K User Threads Kernel Threads One-to-One User Threads K K K K Kernel Threads Many-to-Many User Threads K Kernel Threads One-to-Many Concurrency Correctness What does it mean to run two threads concurrently? Scheduler is free to run threads in any order Dispatcher can choose to run threads to completion or in time slices in various chunks Correct threading means that programs work under all possibilities Independent Threads Cooperating Threads Shared State between threads Non-deterministic Non-reproducible No state shared with other threads Deterministic => Input state determines results Reproducible => Can recreate starting conditions Scheduling order doesn t matter Non-deterministic and Non-reproducible means bugs can be intermittent

6 Why allow cooperating Shared resource One computer, many users Speedup Overlap I/O and computation Multiprocessor Modularity Divide and Conquer Makes it easier to extend Thread Cooperation Voting Example: 1: processvote(id){ 2: c = getcandidate(id); 3: c++; 4: storevote(id, c); 5: How to speed it up? Process more than one request at a time Problem 1: processvote(id){ 2: c = getcandidate(id); 3: c++; 4: storevote(id, c); 5: Most of the time everything is fine, but a race condition exists If two threads make the call with the same id and a context switch happens after line 2, but before line 3, what is the value of the stored c? Atomic Operations Calls that are guaranteed to run to completion or not at all On most machines memory references and assignments of words are atomic Many instructions are not Threaded programs must work for all possible interleaving of context switching Example: Therac - 25 Definitions Machine for radiation therapy Software control or electron accelerator and and beam/xray production Software control of dosage Software error caused the deaths of several patients Race conditions on shared variables They determined that data entry speed during editing was a key factor in producing the error conditions. Synchronization Using atomic operations to ensure cooperation Mutual Exclusion Ensuring that only one thread does a particular thing at a time Critical Section Piece of code that only one thread at a time should execute Lock Prevents someone from doing something Lock before a critical section Unlock when leaving

7 Another Example 1:getMilk(){ 2: if(nomilk) 3: buymilk(); 5: Lets try to leave a note that we are changing the vote Milk Example 2:if(noMilk){ 3: if(nonote){ 4: leave Note; 6: remove Note; 7: 8: What s wrong now? What if the first thing we do is leave a note Milk Example 2:leave Note; 3:if(noMilk){ 4: if(nonote){ 6: 7: 8:remove Note; No one is getting Milk How about two Notes? Milk Example Thread 1 Thread 2 2:leave Note A; 3:if(noMilk){ 4: if(nonote B){ 6: 7: 8:remove Note A; 2:leave Note B; 3:if(noMilk){ 4: if(nonote A){ 6: 7: 8:remove Note B; Context Switch may cause each thread to think the other one is getting Milk (Starvation) Milk Example Thread 1 Thread 2 2:leave Note A; 3:while(note B){ 4:if(noMilk){ 6: 7:remove Note A; This works 2:leave Note B; 3:if(noNote A){ 4: if(nomilk){ 6: 7: 8:remove Note B; Solution Discussion Works, but unsatisfactory This protects a single piece of Critical- Section code Only protects for two threads Thread 1 s code is different from Thread 2 s Better Solution Hardware provide better atomic primitives Build higher-level programming abstractions on this

8 Better Solution lock.acquire(); if(nomilk) buymilk(); lock.release(); Suppose we have an implementation of a Lock Lock.acquire(): waits until a lock is free, then grabs it Lock.release(): unlocks, wake up anyone waiting Then, the milk problem is simple Implementing Locks Atomic Load/Store Get solution similar to our solution to the Milk problem Complex and error prone Hardware Lock Instruction Each feature makes hardware more complex and slow What about putting a task to sleep? Lock via interupt Remember dispatcher gets control when: Threads relinquish CPU Interrupt causes the dispatcher to take CPU Naive implementation of locks: LockAcquire{disable Ints; LockRelease{enable Ints; Why is this a bad idea? Better implementation Acquire(){ disable_int; if(val == BUSY){ wait thread; sleep; else{ val = BUSY; enable_int; Release(){ disable_int; if(anyone waiting){ get thread; place on ready; else{ val = FREE; enable_int; Maintain a lock variable and impose Mutual Exclusion during changes to that variable How to re-enable in Where to re-enable interrupts? Can t do it before wait thread Can t do it after wait thread Can t do it after sleep Acquire(){ disable_int; if(val == BUSY){ wait thread; sleep; else{ val = BUSY; enable_int; How to re-enable in In Nachos ints are disabled when calling sleep, or any context switch responsibility of the next thread to re-enable Thread A disable ints sleep return enable ints context switch context switch Thread B return enable ints disable ints sleep

9 Atomic Read-Modify-Write Atomic Read-Modify-Write Problems with interrupt solution Can t give lock implementation to users Doesn t work well on multiprocessor Disabling interrupts on all processors requires messages and can be time consuming Atomic instruction sequences Read a value from memory and write a new value atomically Hardware responsible Can be used on both uniprocessors and multiprocessors test&set(&address): most architectures sets M[address] to 1 and returns original value swap (&address, register): x86 swaps the values of address and registers compare&swap(&address, reg1, reg2): If M[address]==reg1 sets M[address]=reg2 and returns success, otherwise returns failure Locks with test&set int val = 0; Acquire(){ while (test&set(val)); Release(){ val = 0; Problem: Busy-Waiting test&set: Solution 1 Pro Machine can receive interrupts User code can use this lock Works on a multiprocessor Con Very inefficient Priority Inversion If busy thread has higher priority than then one holding the lock we get no progress test&set: Better int guard = 0; int val = FREE; Acquire(){ while(test&set(guard)); if(val == BUSY){ wait thread; sleep & guard = 0; else{ val = BUSY; buard = 0; Release(){ while(test&set(guard)); if(anyone waiting){ get thread; place on ready; else{ val = FREE; guard = 0; Can minimize busy-waiting: similar to minimizing interrupts NOTE: Sleep has to reset guard variable Semaphores Semaphores are a kind of lock First defined by Dijkstra in late 60s Main synchronization primitive used in original UNIX A non-nagative integer value that supports the following two operations: P(): an atomic operation that waits for the semaphore to become positive and decrements it by 1 V(): an atomic operation that increments the semaphore by 1, waking up waiting P, if any

10 Using Semaphores Producer-Consumer Mutual Exclusion (initial value=1) Binary semaphore semaphore.p(); <CRITICAL SECTION> semaphore.v(); Scheduling Constraints (initial value = 0) Thread should wait for something ThreadJoin(){semaphor.P(); ThreadFinish(){semaphor.V(); Problem Definition Producer puts things into a shared buffer Consumer takes them out Limited number of space Don t want them to work in lock step Can have multiple producers and consumers Example: Coke Machine Producer can add coke Consumers take it out Solution with Sempahore fullbuffer = 0; Semaphore emptybuffer = NUM_BUFFERS; Semaphore mutex = 1; Producer(item){ emptybuffer.p(); mutex.p(); Enqueue(item); mutex.v(); fullbuffer.v(); Consumer(item){ fullbuffer.p(); mutex.p(); item = Dequeue(); mutex.v(); emptybuffer.v(); return item; Why do we need the mutex? Is the order of P s and V s important Monitors and Condition Semaphores are dual purpose and can lead to more errors Cleaner solution is to use: Locks for mutual exclusion Condition variables for scheduling constraints Monitor: A lock and zero or more condition variables Condition variable: make it possible to sleep inside the critical section by automatically releasing a lock before sleep Simple Monitor Example Operations on Condition Variables wait(&lock): release lock and sleep Signal(): wake up one waiter Broadcast(): wake up all waiters Lock lock; Condition ready; Queue queue; AddToQueue(item){ lock.acquire(); queue.enqueue(item); ready.signal(); lock.release(); RemoveFromQueue(item){ lock.acquire(); while(queue.isempty()){ ready.wait(&lock); item = queue.dequeue(); lock.release() return item; Why while and not if while(queue.isempty()){ ready.wait(&lock); Depends on the type of scheduling Hoare-style Sinaler gives lock, CPU to waiter Waiter runs immediately Waiter gives up lock and processor when it exits the critical section or sleeps again Mesa-style (Most Operating Systems) Signaler keeps lock and processor Waiter placed on ready queue Need to check conditions after wait

11 Summary Looked at: processes vs. threads concurrency issues synchronization cooperation implementation of concurrency abstractions