Outline of Lecture-09 Synchronization, Critical ❚ Problems with concurrent access to shared data Sections and Semaphores Ø Race condition and critical section Ø General structure for enforce critical section (SGG Chapter 6) ❚ Software based solutions: Ø Simple solution Ø Peterson’s solution Instructor: Dr. Tongping Liu ❚ Hardware based solution Ø Disable interrupts Ø TestAndSet Ø Swap ❚ OS solution -- Semaphore ❚ Using semaphores to solve real issues 1 Department of Computer Science @ UTSA 2
Objectives Threads Memory Model
❚ To introduce the critical-section problem, whose ❚ Conceptual model: solutions can be used to ensure the consistency of Ø Multiple threads run in the same context of a process shared data Ø Each thread has its own separate thread context ❚ To present both software and hardware solutions of ü Thread ID, stack, stack pointer, PC, and GP registers Ø All threads share the remaining process context the critical-section problem ü Code, data, heap, and shared library segments ❚ To introduce the concept of an atomic transaction ü Open files and installed handlers and describe mechanisms to ensure atomicity ❚ Operationally, this model is not strictly enforced: ❚ Shared Data Ø Register values are truly separate and protected, but… Ø at the same logical address space Ø Any thread can read and write the stack of any other Ø at different address space through messages (later in DS) thread
1 Mapping Variable Instances to Memory Different outputs Global var: 1 instance (ptr [data]) Variable Referenced by Referenced by Referenced by instance Local vars main thread?: 1 instance ( peer thread 0?i.m, msgs.m) peer thread 1? [0]: Hello from foo (svar=1) yes yes yes ptr Local var : 2 instances ( char **ptr; /* global */ cnt myid.t0no [peer thread 0’s stack],yes yes [1]: Hello from bar (svar=2) i.m myid.t1yes [peer thread 1’s stack] no no int main() msgs.m ) yes yes yes { myid.t0 no yes no [1]: Hello from bar (svar=1) int i; myid.t1 no no yes pthread_t tid; /* thread routine */ [0]: Hello from foo (svar=2) char *msgs[2] = { What are possiblevoid *thread(voidoutputs? *vargp) "Hello from foo", { "Hello from bar" int myid = (int)vargp; [1]: Hello from bar (svar=1) }; static int cnt = 0; ptr = msgs; [0]: Hello from foo (svar=1) printf("[%d]: %s (svar=%d)\n", for (i = 0; i < 2; i++) myid, ptr[myid], ++cnt); Pthread_create(&tid, } [0]: Hello from foo (svar=1) NULL, thread, [1]: Hello from bar (svar=1) (void *)i); Local sta c var: 1 instance (cnt [data]) ……. Conclusion: different threads may execute in a random order } sharing.c! 6
Concurrent Access to Shared Data What is the problem?
❚ Two threads A and B access a shared variable ❚ Observe: In a time-shared system, the exact “Balance” instruction execution order cannot be predicted § Scenario 1: § Scenario 2: Thread A: Thread B: A1. LOAD R1, BALANCE B1. LOAD R1, BALANCE Balance = Balance + 100 Balance = Balance - 200 A2. ADD R1, 100 B2. SUB R1, 200 A3. STORE BALANCE, R1 Context Switch! Context Switch! A1. LOAD R1, BALANCE B1. LOAD R1, BALANCE A2. ADD R1, 100 B2. SUB R1, 200 A3. STORE BALANCE, R1 Context Switch! B1. LOAD R1, BALANCE B3. STORE BALANCE, R1 A1. LOAD R1, BALANCE B3. STORE BALANCE, R1 B2. SUB R1, 200 A2. ADD R1, 100 § Sequential correct execution § Mixed wrong execution A3. STORE BALANCE, R1 B3. STORE BALANCE, R1 § Balance is effectively § Balance is effectively decreased by 100! decreased by 200!!!
Department of Computer Science @ UTSA 7 What are possible results for this program? 8
2 a = 0; b = 0; // Initial state Common Properties of Two Examples
Thread 1 Thread 2 ❚ There are some shared variables Ø Account T1-1: if (b == 0) T2-1: if (a == 0) Ø a, b ❚ At least one operation is a write operation T1-2: a = 1; T2-2: b = 1; ❚ The results of the execution are non-deterministic, depending on the execution order
99.43% 0.56% 0.01%
a = 1 a = 0 a = 1 a = 1 b = 0 b = 1 b = 1 b = 1 Department of Computer Science @ UTSA 10
Race Conditions Definition of Synchronization
❚ Multiple processes/threads write/read shared data and the ❚ Cooperating processes/threads share data & have outcome depends on the particular order to access effects on each other à executions are NOT shared data are called race conditions reproducible with non-deterministic exec. speed Ø A serious problem for concurrent system using shared variables! ❚ Concurrent executions Ø Single processor à achieved by time slicing How do we solve the problem?! Ø Parallel/distributed systems à truly simultaneous ❚ Need to make sure that some high-level code sections are ❚ Synchronization à getting processes/threads to executed atomically work together in a coordinated manner Ø Atomic operation means that it completes in its entirety without worrying about interruption by any other potentially conflict- causing process
Department of Computer Science @ UTSA 11 12
3 Critical-Section (CS) Problem General Structure for Critical Sections
❚ Multiple processes/threads compete to access the do { shared data …… entry section critical section ❚ Critical section/region: a piece of code that exit section accesses a shared resource (data structure or device) must not be concurrently accessed by more remainder statements than one thread of execution. } while (1); ❚ In the entry section, the process requests ❚ Problem – ensure that only one process/thread is “permission”. allowed to execute in its critical section (for the same shared data) at any time. The execution of critical sections must be mutually exclusive in time.
Department of Computer Science @ UTSA 13 Department of Computer Science @ UTSA 14
Requirements for CS Solutions Mutual Exclusion
❚ Mutual Exclusion Ø At most one task can be in its CS at any time ❚ Progress Ø If all other tasks are in their remainder sections, a task is allowed to enter its CS Ø Only those tasks that are not in their remainder section can decide which task can enter its CS next, and this decision cannot be postponed infinitely. ❚ Bounded Waiting Ø Once a task has made a request to enter its CS à other tasks can only enter their CSs with a bounded number of times
15 Department of Computer Science @ UTSA 16
4 Solutions for CS Problem Outline of Lecture-09
❚ Software based solution ❚ Problems with concurrent access to shared data Ø Peterson’s solution Ø Race condition and critical section Ø General structure for enforce critical section ❚ Hardware based solutions ❚ Software based solutions: Ø Disable interrupts Ø Simple solution Ø Atomic instructions: TestAndSet and Swap Ø Peterson’s solution ❚ Hardware based solution ❚ OS solutions: Ø Disable interrupts Ø Semaphore Ø TestAndSet Ø Swap ❚ OS solution -- Semaphore ❚ Using semaphores to solve real issues Department of Computer Science @ UTSA 17 Department of Computer Science @ UTSA 18
A Simple Solution Peterson’s Solution
❚ Bool turn; à indicate whose turn to enter CS ❚ Three shared variables: turn and flag[2] ❚ T0 and T1: alternate between CS and remainder
Pros: Cons: How does this solution satisfy the CS requirements (mutual exclusion, progress, bounded waiting) ? 1. Pi’s critical section is executed 1. Progress is not satisfied since it iff turn = i requires strict alternation 2. Pi is busy waiting if Pj is in CS 2. A process cannot enter the CS (mutual exclusion) more often than the other 19 20
5 Peterson’s Solution Peterson’s Solution
❚ Guarantee mutual exclusion? ❚ Progress Guarantee? Ø Q: when process 0 is in its critical section, can Ø Q: when P0 is in its remainder section, can P1 get into process1 get into its critical section? its critical section? à flag[0] = 1 and either flag[1]=0 or turn = 0 à flag[0] = 0 à Thus, for process1: under flag[0]=1, if flag[1]=0, P1 is in à Process1: if flag[0]=0, then P1 can enter without its CS reminder section; if turn = 0, it waits before its CS without waiting
21 22
Peterson’s Solution Peterson’s Solution (cont.)
❚ Mutual exclusion ❚ Toggle first two lines for one process ❚ Progress ❚ Bounded waiting: alternation Any issues of Peterson’s solution? ❚ Busy waiting ❚ Each thread should have different code ❚ Can it support more than two threads? How does this solution break the CS requirements ❚ Error-prone (mutual exclusion, progress, bounded waiting) ?
23 24
6 Outline of Lecture-09 Hardware Solution 1: Disable Interrupt
❚ Problems with concurrent access to shared data ❚ Uniprocessors – could disable interrupts Ø Race condition and critical section Ø Currently running code would execute without preemption