Modified from Silberschatz, Galvin and Gagne & Stallings Lecture 10 Chapter 6: Process Synchronization

  • View
    221

  • Download
    0

Embed Size (px)

Text of Modified from Silberschatz, Galvin and Gagne & Stallings Lecture 10 Chapter 6: Process...

  • Slide 1
  • Modified from Silberschatz, Galvin and Gagne & Stallings Lecture 10 Chapter 6: Process Synchronization
  • Slide 2
  • 2 CS 446/646 Principles of Computer Operating Systems Chapter 6: Process Synchronization Background The Critical-Section Problem Petersons Solution Synchronization Hardware Semaphores Classic Problems of Synchronization Monitors Synchronization Examples Atomic Transactions
  • Slide 3
  • 3 CS 446/646 Principles of Computer Operating Systems Objectives To introduce the critical-section problem, whose solutions can be used to ensure the consistency of shared data To present both software and hardware solutions of the critical-section problem To introduce the concept of an atomic transaction describe mechanisms to ensure atomicity
  • Slide 4
  • 4 CS 446/646 Principles of Computer Operating Systems Background Concurrent access to shared data may result in data inconsistency concurrency is a fundamental part of O/S design concurrency includes communication among processes/threads sharing of, and competition for system resources cooperative processing of shared data synchronization of process/thread activities organized CPU scheduling solving deadlock and starvation problems Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes
  • Slide 5
  • 5 CS 446/646 Principles of Computer Operating Systems Concurrency can be viewed at different levels: multiprogramming interaction between multiple processes running on one CPU (pseudo-parallelism) multithreading interaction between multiple threads running in one process multiprocessors interaction between multiple CPUs running multiple processes/threads (real parallelism) multicomputers interaction between multiple computers running distributed processes/threads the principles of concurrency are basically the same in all of these categories Process Interaction & Concurrency Software view Hardware view
  • Slide 6
  • 6 CS 446/646 Principles of Computer Operating Systems o processes unaware of each other they must use shared resources independently, without interfering, and leave them intact for the others P1P1 P2P2 resource o processes indirectly aware of each other they work on common data and build some result together via the data P2P2 P1P1 data o processes directly aware of each other they cooperate by communicating, e.g., exchanging messages P2P2 P1P1 messages Whether processes or threads: three basic interactions Process Interaction & Concurrency
  • Slide 7
  • 7 CS 446/646 Principles of Computer Operating Systems Multithreaded shopping diagram and possible outputs >./multi_shopping grabbing the salad... grabbing the milk... grabbing the apples... grabbing the butter... grabbing the cheese... > >./multi_shopping grabbing the milk... grabbing the butter... grabbing the salad... grabbing the cheese... grabbing the apples... > Molay, B. (2002) Understanding Unix/Linux Programming (1st Edition). Insignificant race condition in the shopping scenario there is a race condition if the outcome depends on the order of the execution Race Condition
  • Slide 8
  • 8 CS 446/646 Principles of Computer Operating Systems CPU Insignificant race condition in the shopping scenario the outcome depends on the CPU scheduling or interleaving of the threads (separately, each thread always does the same thing) >./multi_shopping grabbing the salad... grabbing the milk... grabbing the apples... grabbing the butter... grabbing the cheese... > A B salad apples milk buttercheese >./multi_shopping grabbing the milk... grabbing the butter... grabbing the salad... grabbing the cheese... grabbing the apples... > A salad apples B milk buttercheese Race Condition
  • Slide 9
  • 9 CS 446/646 Principles of Computer Operating Systems Insignificant race condition in the shopping scenario the CPU switches from one process/thread to another, possibly on the basis of a preemptive clock mechanism >./multi_shopping grabbing the salad... grabbing the milk... grabbing the apples... grabbing the butter... grabbing the cheese... > A B salad apples milk buttercheese CPU thread A thread B salad milk apples buttercheese Thread view expanded in real execution time Race Condition
  • Slide 10
  • 10 CS 446/646 Principles of Computer Operating Systems char chin, chout; void echo() { do { chin = getchar(); chout = chin; putchar(chout); } while (...); } A char chin, chout; void echo() { do { chin = getchar(); chout = chin; putchar(chout); } while (...); } B >./echo Hello world! Single-threaded echo Multithreaded echo (lucky) >./echo Hello world! 1 2 3 4 5 6 lucky CPU scheduling Significant race conditions in I/O & variable sharing Race Condition
  • Slide 11
  • 11 CS 446/646 Principles of Computer Operating Systems char chin, chout; void echo() { do { chin = getchar(); chout = chin; putchar(chout); } while (...); } A >./echo Hello world! Single-threaded echo char chin, chout; void echo() { do { chin = getchar(); chout = chin; putchar(chout); } while (...); } B Significant race conditions in I/O & variable sharing 1 5 6 2 3 4 unlucky CPU scheduling Multithreaded echo (unlucky) >./echo Hello world! ee.... Race Condition
  • Slide 12
  • 12 CS 446/646 Principles of Computer Operating Systems void echo() { char chin, chout; do { chin = getchar(); chout = chin; putchar(chout); } while (...); } B void echo() { char chin, chout; do { chin = getchar(); chout = chin; putchar(chout); } while (...); } A >./echo Hello world! Single-threaded echo Significant race conditions in I/O & variable sharing 1 5 6 2 3 4 unlucky CPU scheduling Multithreaded echo (unlucky) >./echo Hello world! eH.... changed to local variables Race Condition
  • Slide 13
  • 13 CS 446/646 Principles of Computer Operating Systems Significant race conditions in I/O & variable sharing in this case, replacing the global variables with local variables did not solve the problem we actually had two race conditions here: one race condition in the shared variables and the order of value assignment another race condition in the shared output stream: which thread is going to write to output first this race persisted even after making the variables local to each thread generally, problematic race conditions may occur whenever resources and/or data are shared by processes unaware of each other or processes indirectly aware of each other Race Condition
  • Slide 14
  • 14 CS 446/646 Principles of Computer Operating Systems Producer / Consumer Problem Suppose that we wanted to provide a solution to the consumer-producer problem that fills all the buffers. We can do so by having an integer count that keeps track of the number of full buffers. Initially, count is set to 0. incremented by the producer after it produces a new buffer, decremented by the consumer after it consumes a buffer. http://gaia.ecs.csus.edu/~zhangd/oscal/ProducerConsumer/Producer Consumer.html http://gaia.ecs.csus.edu/~zhangd/oscal/ProducerConsumer/Producer Consumer.html while (true) { /* Produce an item */ while (((in = (in + 1) % BUFFER SIZE) == out) ; /* do nothing -- no free buffers */ buffer[in] = item; in = (in + 1) % BUFFER SIZE; } while (true) { while (in == out) ; // do nothing -- nothing to consume // remove an item from the buffer item = buffer[out]; out = (out + 1) % BUFFER SIZE; return item; }
  • Slide 15
  • 15 CS 446/646 Principles of Computer Operating Systems Producer / Consumer while (true) { /* produce an item and put in nextProduced */ while (count == BUFFER_SIZE) ; // do nothing buffer [in] = nextProduced; in = (in + 1) % BUFFER_SIZE; count++; } while (true) { while (count == 0) ; // do nothing nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; count--; /* consume the item in nextConsumed }
  • Slide 16
  • 16 CS 446/646 Principles of Computer Operating Systems Race Condition count++ could be implemented as register1 = count register1 = register1 + 1 count = register1 count-- could be implemented as register2 = count register2 = register2 - 1 count = register2 Consider this execution interleaving with count = 5 initially: S0: producer execute register1 = count {register1 = 5} S1: producer execute register1 = register1 + 1 {register1 = 6} S2: consumer execute register2 = count {register2 = 5} S3: consumer execute register2 = register2 - 1 {register2 = 4} S4: producer execute count = register1 {count = 6 } S5: consumer execute count = register2 {count = 4}
  • Slide 17
  • 17 CS 446/646 Principles of Computer Operating Systems How to avoid race conditions? find a way to keep the instructions together this means actually... reverting from too much interleaving and going back to indivisible/atomic blocks of execution!! thread A thread B chin='H' chin='e' putchar('e') chout='e'putchar('e') (a) too much interleaving may create race conditions (b) keeping indivisible blocks of execution avoids race conditions thread A thread B chin='H' chin='e' putchar('H') chout='e'putchar('e') Race Condition
  • Slide 18
  • 18 CS 446/646 Principles of Computer Operating Systems The indivisible execution blocks are critical regions a critical region is a section of code that may be executed by only one process or thread at a time B A common critical region B A As critical region Bs critical region although it is not necessarily the same region of memory or section of program in both processes but physically different or not, what ma

Search related