Concurrency: Background and Implementation

Fred Kuhns(fredk@arl.wustl.edu, http://www.arl.wustl.edu/~fredk)Department of Computer Science and EngineeringWashington University in St. Louis

*

Origins of ConcurrencyProcesses need to communicate, issues:How is information exchanged between processes (shared memory or messages)?How to prevent interference between cooperating processes (mutual exclusion)?How to control the sequence of process execution (conditional synchronization)?Execution of the kernel (interrupts, exception, traps) often results in the need for concurrent access to state and deferred processing pending an event.

*

Problems Shared MemoryConcurrent programs may exhibit a dependency on process/thread execution sequence or processor speed (neither are desirable!)race condition whos first, and who goes next. affects program results.There are two basic issues resulting from the need to support concurrency:Mutual exclusion: ensure that processes/threads do not interfere with one another, i.e. there are no race conditions. In other words, program constraints (assumptions) are not violated.Conditional synchronization: Processes/threads must be able to wait for the data to arrive or constraints (assertions) to be satisfied.

*

PreliminariesConsider a process as a sequence of statements which are implemented as one or more primitive atomic operations (hardware instructions)Concurrent program results in the interleaving of statements from different processesProgram state is value of variables at a given point in time. Execution viewed as a sequence of states si,. Atomic actions transform states.Program history is sequence of states: s0 -> s1 -> ... -> sNSynchronization constrains the set of possible histories to only those that are desirableMutual Exclusion combines a sequence of actions into a critical section which appear to execute atomically.

*

Race Conditions - ExampleThere are 4 cases:case 1: task A runs to completion first loading y=0, z=0. x = 0 + 0 = 0case 2: Task B runs and sets y to 1, then Task A runs loading y=1 and z=0. x = 1 + 0 = 1case 3: Task A runs loading y=0, then Task B runs to completion, then Task A runs loading z=2. x = 0 + 2 = 2case 4: Task B runs to completion, then Task A runs loading y=1, z=2,x = 1 + 2 = 3

Example 1int y = 0, z = 0;Task A { x = y + z} Task B {y = 1; z = 2}Results:x = {0, 1, 2, 3}load y into R0load z into R1set R0 = R0 + R1set R0 -> x

*

Race Condition: OS Example

KFT_NextFree = 7Task A:...get KFT_NextFree (7)-- preempted -

KFT_NextFree += 1;update entry 7Task B:...

get KFT_NextFree (7)KFT_NextFree += 1;update Entry 7-- preemptFinal value of kernel table entry 7 is indeterminate.Final value of KFT_NextFree is 9Kernel File Table entry 8 is not allocated

*

At-Most-Once PropertyDefinitions:Independent processes: Two processes are independent if the write set of each is disjoint from both the read and write sets of the other.Critical reference: reference to variable changed by another process.At-Most-Once property: If the assignment stment (x = e) satisfies (1) e contains at most one critical reference and x is not read by another process or (2) e contains no critical references, in which case x may be read by another process.there can be at most one shared variable and it can be referenced at most once.If (x = e) satisfies AMO then it appears to be atomic

*

Critical Section ProblemEntry/exit protocol satisfies:Mutual Exclusion: At most one in CSAbsence of deadlock/livelock:2 or more threads then at least one enters CS.Absence of Unnecessary delay:Only 1, then it must entry: other threads not in CS or have terminated.Eventual entry: thread cant wait forever no starvation. May be influenced by scheduling policy.Task A { while (True) { entry protocol; critical section; exit protocol; non-critical section; }}

*

Mutual Exclusion Busy waitingInterrupt disabling:Process runs until requests OS service or interruptedProcess disables interrupts for MUTEXProcessor has limited ability to interleave programsEfficiency of execution may be degradedMultiprocessingdisabling interrupts on one processor will not guarantee mutual exclusion

*

Mutual Exclusion: Help from HardwareYou have the lock iff False is returnedif lock == False before calling TSL(lock)it is set to True and False is returnedif lock == True before calling TSL(lock)it is set to True and True is returned

(Return original value of lock)boolean Test&Set (boolean &lock) {boolean tmp = lock;lock = True;return tmp;}

*

Mutual Exclusion with TSLShared data: boolean lock = False; // initialize to falseTask Pi

do {// Entry protocolwhile (TSL(lock) == True) ; // spin: wait for lock// execute critical section code-- critical section --// Exit protocollock = False;// Non-critical section code-- remainder section --} while (1);

*

Machine InstructionsAdvantages Applicable multiple processes on single or multi-processor systems (using shared memory) It is simple and therefore easy to verifyIt can be used to support multiple critical sectionsDisadvantagesBusy-waiting consumes processor timeStarvation possible when a process leaves a critical section and more than one process is waiting. Who is next?Deadlock - If a low priority process has the critical region (i.e. lock) but is preempted by a higher priority process spinning on lock then neither can advance.

*

Must we always busy wait?While busy waiting is useful in some situations it may also lead to other problems: inefficient use of CPU and deadlock resulting from a priority inversionWhat we really want is a way to combine mutual exclusion schemes with conditional synchronization.In other words, we want the option of blocking a process until it is able to acquire the mutual exclusion lock.Simple solution is to add two new functions: sleep() and wakeup()

*

Adding Conditional Synchronization

int N 10int buf[N];int in = 0, out = 0, cnt = 0; Task consumer {item_t item;while (TRUE) {if (cnt == 0) sleep();item = buf[out];out = (out + 1) % N; lock(lock);cnt--;unlock(lock);if (cnt == N-1)wakeup(producer);consume(item);}}Task producer {int item;while (TRUE) {item = mkitem();if (cnt == N) sleep();buf[in] = item;in = (in + 1) % N;lock(lock);cnt++;unlock(0);if (cnt == 1)wakeup(consumer);}}

*

Lost wakeup problemAssume that the lock() and unlock() functions implement a simple spin lock.There is a race condition that results in a lost wakeup, do you see it?

*

Intro to SemaphoresSynchronization mechanism:No busy waiting and No lost wakeup problem.Integer variable accessible via two indivisible (atomic) operations :P(s) or wait(s): If s > 0 then decrement else block thread on semaphore queue V(s) or signal(s): if s value--;while (S->value < 0) {addthread(S->sq);sleep();}return;}void signal(sem_t *S){thread_t t;S->value++;if (S->value 0) {t = getthread(S->sq);wakeup(t);}return;}

*

Some Reference BackgroundSemaphores used in Initial MP implementationsThreads are woken up in FIFO order (convoys) forcing a strictly fifo order may result in unnecessary blockingUsed to provideMutual exclusion (initialized to 1)Event-waiting (initialized to 0)Resource counting (initialized to number available)