CS 361 Concurrent programming Dreel University Fall 2004 Lecture 6 Bruce Char and Vera Zaychik. All rights reserved by the author. Permission is given to students enrolled in CS361 Fall 2004 to reproduce these notes for their own use. Memory system behavior: volatile variables Another scenario: Java changes several variables (initially = 0; y = 0); Thread 1 starts, = 1; y = 2; = 3; y = 4; Thread 2 reads values of variable then variable y, then variable again. Suppose that the first time it reads, its value is 0. It then reads y and finds the value of 4. What values could it see if it then reads? page 1 page 2 Volatile variables and concurrency Answer: could be 0, 1, 3, or 5, or. Reason: cache updates of y may occur independently of cache updates of. This can cause problems in concurrent programming you can t use one variable to signal that another shared variable is ready. The volatile keyword If a field is declared volatile, any value written to it is flushed and made visible by the writer thread before the writer thread performs any further memory operation. Reader threads must reload the values of volatile fields from main memory upon each access. page 3 page 4 The Java Language Reference on volatile variables The Java language allows threads that access shared variables to keep private working copies of the variables; this allows a more efficient implementation of multiple threads. These working copies need be reconciled with the master copies in the shared main memory only at prescribed synchronization points. The Java Language Reference on declaring a variable to be volatile a field may be declared volatile, in which case a thread must reconcile its working copy of the field with the master copy every time it accesses the variable. Moreover, operations on the master copies of one or more volatile variables on behalf of a thread are performed by the main memory in eactly the order that the thread requested. page 5 page 6
Volatile variables in Java Declaring class members to be volatile: public volatile int =0,y=0; means, among other things, that multiple threads observing changes to the value of and y by a single thread will see them occur in the same order that they were performed. Volatile variables at work volatile int,y; Thread #1 assigns = 0; y = 1; = 2; y =3; =4; y=5; =6; y=7; Thread #2 reads y, finds it is 3. s value can t be but can be. can t be 0, 6, 8, but could be 2 or 4 (why?). page 7 page 8 Volatile variables, continued volatile int =0; Thread #1 assigns =1; Thread #2 then reads. What value will it see? Volatile variables, continued Answer: #2 could see either 0 or 1. Thread #2 could be looking at either before or after #1 has finished reconciling main memory with the changed value of in its cache. page 9 page 10 Producer/consumer problem Producer/consumer at work A producer produces items. A consumer consumes them. Want the producer and consumer to operate with minimal synchronization. The producer puts produced items into a warehouse (buffer). The consumer takes items out of the warehouse. producer consumer producer page 11 X consumer page 12
Producer/consumer problem Producer/consumer at work Sometimes the producer produces items faster than the consumer consumes them, so the warehouse/buffer begins to fill. When the producer gets far enough ahead of consumption so that the warehouse/buffer is filled, the producer must block until the warehouse/buffer has an available spot. page 13 producer producer wants to put another item in buffer, but must wait until consumer takes one out page 14 consumer wants to consume, but must wait until producer puts an item in the buffer consumer Producer/consumer problem If the buffer has a store of items, then the consumer can consume faster than the producer produces them until the buffer is empty. Then the consumer must block. Producer/consumer problem Concurrency problem: only want the consumer to take out items when there are some there. Only want the producer to put in more items when the buffer isn t full. Otherwise, let the two operate independently, possibly at different rates and times. page 15 page 16 page 17 Producer code, a first try public void deposit(double value) { //Each item of buffer array has two fields: // occupied (boolean),and value (a double) while (buffer [putin].occupied) // yield moves from running to runnable -- busy waiting buffer[putin].value = value; // A buffer[putin].occupied = true; // B putin = (putin+1) % numslots; count++ // race condition! page 18 Consumer code, a first try public double fetch() { // if the net empty spot is full, wait. while (!buffer [takeout].occupied) // Take the value out of the buffer consumedvalue = buffer[takeout].value; // C buffer[takeout].occupied = false; // D takeout = (takeout + 1) % numslots; count --; // race condition! return value;
page 19 Volatility problems If the producer thread does A (changing value) and then B (changing occupied), but the producer thread sees the updates in the reverse order then there will be incorrectness. Producer thread Consumer thread buffer[putin].value = 3; (was 2) buffer[putin].occupied = true;!buffer [takeout].occupied is false consumedvalue = buffer[takeout].value; // C consumedvalue is 2 page 20 Solution to volatility problems Solution: declare the data members to be volatile. There s a similar problem with the producer seeing the consumer s changes through lines C and D. page 21 Other race conditions Can t have the producer and the consumer both trying to change the count variable at the same time, assuming that the ++ and -- are implemented as a sequence of machine language instructions. There is also a problem with takein and putout if there were multiple producers or multiple consumers. Fortunately there isn t a problem as long as there s only one producer and consumer. page 22 Critical section A critical section is a sequence or block of code run by a thread that References one or more variables in a read/update/write fashion while any of those variables is possibly being altered by another thread. Alters one or more variables that are being referenced in a read/update/write fashion by another thread. Critical section, continued A critical section is (also) a sequence or block of code run by a thread that Uses a data structure such as a linked list while any part of it is being possibly altered by another thread. Alters any part of a data structure such as a linked list while it is possibly in use by another thread. Mutual eclusion To prevent race conditions and lost updates, only one thread at a time should be allowed to eecute a critical section of code (having to do with shared data). It s okay to eecute critical sections having to do with different data simultaneously by multiple threads, it s just unsafe to eecute multiple threads/processes on sections affecting the same data. page 23 page 24
Protecting critical sections from multiple concurrent entry Preprotocol/entry protocol and a postprotocol/eit protocol to protect critical section. while(true) { Non critical section page 25 WantToEnterCS(..); // preprotocol; Critical section code FinishedInCS( ); // postprotocol page 26 Pre- and post- CS protocols WantToEnterCS(.) Serves as a gatekeeper only lets one thread through at a time. While the first thread through the gate is in the critical section, all the other threads eecuting WantToEnterCS are prevented from leaving it (the gate is closed). FinishedWithCS( ) Notifies the gatekeeper that the thread in the CS is done; will now let another thread eecuting WantToEnterCS through. Two aspects of the mutual eclusion problem Implementing the pre- and post- protocols Correct iron-clad mutual eclusion Works with any number of threads (1, 2, or more) Using the pre- and post-protocols to correctly provide mutual eclusion where they are needed Things that can go wrong in concurrency Recall that you can t make any assumptions about the number of CPUs or their relative speeds. Should be no deadlock two threads each waiting for the other to say something. Each thread in a deadlocked set of threads is blocked, waiting for another event to occur that can only be triggered by another thread in the set of deadlocked thread. page 27 page 28 More things that can go wrong Livelock it is not impossible for the threads to escape the preprotocol, but because of the program logic the threads may loop for a long time in it before anyone gets out. No thread outside of its critical section should be able to block other threads from entering the critical section ( absence of unnecessary delay criterion). No thread should have to wait forever ( no starvation criterion) More things that can go wrong Starvation in the absence of contention a thread can t enter its critical section even though nothing is really blocking it. Starvation in the presence of contention: several threads want to get in, some get in multiple times, some threads who want to get in never get in. page 29 page 30
Software providing mutual eclusion In the book s discussion of solutions to the mutual eclusion problem, Hartley assumes Standard load/store register architecture Multiply eecuting concurrent threads that share data Single or multiple CPUs that may be identical or different in speeds Access to shared variables can be interleaved if two threads get into their critical sections in time. More assumptions Threads do not halt or crash in their pre/post protocols, or in their critical sections, but may halt or crash outside of critical sections. page 31 page 32 Hardware support for mutual eclusion Definition of an atomic instruction a machine language instruction that is eecuted completely without being interruptible no interleaving of other instructions from another thread no contet switching no hardware interrupts. Software solutions for mutual eclusion: attempt #1 Use busy waiting. boolean lockflag = false; WantToEnterCS(int I) { // thread #I wants to enter while(lockflag) {; // busy wait // loops until lockflag is false; // hopefully other thread will set this false. lockflag=true; finishedincs(int I) { lockflag = false; page 33 page 34 What s wrong with this? Problem: we can have a race condition ThreadA: load lockflag into R Contet switch from thread A to B ThreadB: load lockflag into R Compare value: it s false Store true to lockflag Enter critical section Contet switch from thread B back to A Thread A: compare R and value: it s false, so proceed Store true to lockflag Enter critical section So both can be in critical section at same time. page 35 page 36 Attempt #2 Use a turn variable: int turn =0; is either 0 or 1 public void WanttoEnterCS(int i) { while (turn!=i) // go from running back to run queue give someone else a // chance. public void finishedincs(int i) { turn = other(i); // this sets I to something other than i
What s the matter with this? Hint -- what happens if there s only one thread that wants to run? This is Starvation in the absence of contention. Attempt #3 // Use a flag class again. class Flag {public volatile boolean value = false; // In class that handles mutual eclusion.. private Flag[] desirecs = new Flag[2]; // array of flags. for (int I = 0; I<2; I++) desirecs[i] = new Flag(); // initialize with new flag objects public void wanttoentercs(int I) { while (desirecs[other(i)].value) Thread.currentthread().yield(); // busy wait desirecs[i].value = true; // set your flag page 37 public void finishedincs(int I) { desirecs[i].value = false; // unset flag page 38 page 39 What s wrong with this? Hint: race condition. If both threads eecute the while at the same time, neither flag will yet be set, so they will both proceed into the critical section. So there s no mutual eclusion. page 40 Attempt #4 Try fiing flags public void wanttoentercs(int I) { desirecs[i].value = true; while (desirecs[other(i)].value) { post-protocol FinishedWithCS same as before public void finishedincs(int I) { desirecs[i].value = false; // unset flag Eercise This doesn t work as a way of ensuring mutual eclusion. Describe a scenario where the code fails to work properly. Can you find more than one kind of scenario where the code fails? page 41