Concurrency: Background and Implementation

1. Concurrency: Background and Implementation Fred Kuhns (fredk@arl.wustl.edu, http://www.arl.wustl.edu/~fredk) Department of Computer Science and Engineering Washington University in St. Louis

2. Origins of Concurrency • Processes 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. Cs422 – Operating Systems Organization

3. Problems – Shared Memory • Concurrent programs may exhibit a dependency on process/thread execution sequence or processor speed (neither are desirable!) • race condition – who’s 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. Cs422 – Operating Systems Organization

4. Preliminaries • Consider 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 processes • Program 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 -> ... -> sN • Synchronization constrains the set of possible histories to only those that are desirable • Mutual Exclusion combines a sequence of actions into a critical section which appear to execute atomically. Cs422 – Operating Systems Organization

5. Race Conditions - Example • There are 4 cases: • case 1: task A runs to completion first loading y=0, z=0. x = 0 + 0 = 0 • case 2: Task B runs and sets y to 1, then Task A runs loading y=1 and z=0. x = 1 + 0 = 1 • case 3: Task A runs loading y=0, then Task B runs to completion, then Task A runs loading z=2. x = 0 + 2 = 2 • case 4: Task B runs to completion, then Task A runs loading y=1, z=2,x = 1 + 2 = 3 Example 1 int y = 0, z = 0; Task A { x = y + z} Task B {y = 1; z = 2} Results: x = {0, 1, 2, 3} load y into R0 load z into R1 set R0 = R0 + R1 set R0 -> x Cs422 – Operating Systems Organization

6. Kernel File Table 0 myfile.c: attributes myfile.o: attributes 1 ... NULL 7 ... Race Condition: OS Example Task A: ... get KFT_NextFree (7) -- preempted –- KFT_NextFree += 1; update entry 7 Task B: ... get KFT_NextFree (7) KFT_NextFree += 1; update Entry 7 -- preempt KFT_NextFree = 7 • Final value of kernel table entry 7 is indeterminate. • Final value of KFT_NextFree is 9 • Kernel File Table entry 8 is not allocated Cs422 – Operating Systems Organization

7. At-Most-Once Property • Definitions: • 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 Cs422 – Operating Systems Organization

8. Critical Section Problem Entry/exit protocol satisfies: • Mutual Exclusion: At most one in CS • Absence 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 can’t wait forever – no starvation. May be influenced by scheduling policy. Task A { while (True) { entry protocol; critical section; exit protocol; non-critical section; } } Cs422 – Operating Systems Organization

9. Mutual Exclusion – Busy waiting • Interrupt disabling: • Process runs until requests OS service or interrupted • Process disables interrupts for MUTEX • Processor has limited ability to interleave programs • Efficiency of execution may be degraded • Multiprocessing • disabling interrupts on one processor will not guarantee mutual exclusion Cs422 – Operating Systems Organization

10. Mutual Exclusion: Help from Hardware (Return original value of lock) boolean Test&Set (boolean &lock) { boolean tmp = lock; lock = True; return tmp; } You have the lock iff False is returned • if lock == False before calling TSL(lock) • it is set to True and False is returned • if lock == True before calling TSL(lock) • it is set to True and True is returned Cs422 – Operating Systems Organization

11. Mutual Exclusion with TSL • Shared data: boolean lock = False; // initialize to false • Task Pi do { // Entry protocol while (TSL(lock) == True) ; // spin: wait for lock // execute critical section code -- critical section -- // Exit protocol lock = False; // Non-critical section code -- remainder section -- } while (1); Cs422 – Operating Systems Organization

12. Machine Instructions • Advantages • Applicable multiple processes on single or multi-processor systems (using shared memory) • It is simple and therefore easy to verify • It can be used to support multiple critical sections • Disadvantages • Busy-waiting consumes processor time • Starvation 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. Cs422 – Operating Systems Organization

13. 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 inversion • What 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() Cs422 – Operating Systems Organization

14. Adding Conditional Synchronization int N 10 int buf[N]; int in = 0, out = 0, cnt = 0; 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); } } 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); } } Cs422 – Operating Systems Organization

15. Lost wakeup problem • Assume 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? Cs422 – Operating Systems Organization

16. Intro to Semaphores • Synchronization 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 <= 0 then wake one sleeping thread, else increment s. • Each Semaphore has an associated queue. • Can define a non-blocking version of wait(s). Cs422 – Operating Systems Organization

17. Critical Section of n Tasks • Shared data: semaphore mutex; // initialize mutex = 1 • Process Ti: do {wait(mutex); -- critical section -- signal(mutex); -- remainder section – } while (1); Cs422 – Operating Systems Organization

18. Semaphore Implementation • Define a semaphore as a record typedef struct { int value; // value of semaphore queue_t sq; // task/thread queue } semaphore; • Assume two simple operations: • block suspends the task/thread that invokes it. • wakeup(T) resumes the execution of a blocked task/thread T. Cs422 – Operating Systems Organization

19. Implementation - Threads void signal(sem_t *S) { thread_t t; S->value++; if (S->value  0) { t = getthread(S->sq);wakeup(t); } return; } void wait(sem_t *S) { S->value--; while (S->value< 0) { addthread(S->sq); sleep(); } return; } Cs422 – Operating Systems Organization

20. Some Reference Background • Semaphores used in Initial MP implementations • Threads are woken up in FIFO order (convoys) • forcing a strictly fifo order may result in unnecessary blocking • Used to provide • Mutual exclusion (initialized to 1) • Event-waiting (initialized to 0) • Resource counting (initialized to number available) Cs422 – Operating Systems Organization