synchronization (1)
DESCRIPTION
Synchronization (1). Acknowledgements. All the lecture slides were adopted from the slides of Andy Wellings. Communication and Synchronization. Lecture Aims - PowerPoint PPT PresentationTRANSCRIPT
EEL 6897 1
Synchronization (1)
EEL 6897 2
Acknowledgements
ā¢ All the lecture slides were adopted from the slides of Andy Wellings
EEL 6897 3
Communication and Synchronization
Lecture Aims
ā¢ To understand synchronized methods and statements and how they can be used with the wait and notify methods to implement simple monitors
ā¢ To show how to implement the Bounded Buffer communication paradigm
EEL 6897 4
Synchronized Methodsā¢ There is a mutual exclusion lock associated with each
object which cannot be accessed directly by the application but is affected by
ā the method modifier synchronized
ā block synchronization
ā¢ When a method is labeled as synchronized, access to the method can only proceed once the system has obtained the lock
ā¢ Hence, synchronized methods have mutually exclusive access to the data encapsulated by the object, if that data is only accessed by other synchronized methods
ā¢ Non-synchronized methods do not require the lock and, therefore, can be called at any time
EEL 6897 5
Example of Synchronized Methodsclass SharedInteger {
public SharedInteger(int initialValue) { theData = initialValue; } public synchronized int read() { return theData; } public synchronized void write(int newValue) { theData = newValue; }
public synchronized void incrementBy(int by) { theData = theData + by; }
private int theData;}
SharedInteger myData = new SharedInteger(42);
EEL 6897 6
Block Synchronizationā¢ A mechanism where a block can be labeled as synchronized
ā¢ The synchronized keyword takes as a parameter an object whose lock the system needs to obtain before it can continue
ā¢ Synchronized methods are effectively implementable as
public int read() {
synchronized(this) {
return theData;
}
}ā¢ this is the Java mechanism for obtaining the current object
EEL 6897 7
Warning
ā¢ Used in its full generality, the synchronized block can undermine one of the advantages of monitor-like mechanisms, that of encapsulating synchronization constraints associate with an object into a single place in the program
ā¢ This is because it is not possible to understand the synchronization associated with a particular object by just looking at the object itself when other objects can name that object in a synchronized statement
ā¢ However with careful use, this facility augments the basic model and allows more expressive synchronization constraints to be programmed
EEL 6897 8
Accessing Synchronized Data
ā¢ Consider a simple class which implement a two-dimensional coordinate that is to be shared between two or more threads
ā¢ This class encapsulates two integers, whose values contain the x and the y coordinates
ā¢ Writing to a coordinate is simple, the write method can be labelled as synchronized
ā¢ Furthermore, the constructor method can be assumed not to have any synchronization constraint
EEL 6897 9
Shared Coordinate I
public class SharedCoordinate { public SharedCoordinate(int initX, int initY) { x = initX; y = initY; }
public synchronized void write(int newX,
int newY) { x = newX; y = newY; } ...
private int x, y;
}
EEL 6897 10
Shared Coordinate II
ā¢ How to read the value of the coordinates?
ā¢ Functions in Java can only return a single value, and parameters to methods are passed by value
ā¢ Consequently, it is not possible to have a single read method which returns both the x and the y values
ā¢ If two synchronized functions are used, readX and readY, it is possible for the value of the coordinate to be written in between the calls to readX and readY
ā¢ The result will be an inconsistent value of the coordinate
EEL 6897 11
Solution 1
ā¢ Return a new Coordinate object whose values of the x and y fields are identical to the shared coordinate
ā¢ This new object can then be accessed without fear of it being changed
public class SharedCoordinate { ...
public synchronized SharedCoordinate read() { return new SharedCoordinate(x, y); } public int readX() { return x; } public int readY() { return y; } }
EEL 6897 12
Notes
ā¢ The returned coordinate is only a snapshot of the shared coordinate, which might be changed by another thread immediate after the read method has returned
ā¢ The individual field values will be consistent
ā¢ Once the returned coordinate has been used, it can be discarded and made available for garbage collection
ā¢ If efficiency is a concern, it is appropriate to try to avoid unnecessary object creation and garbage collection
EEL 6897 13
Solution 2ā¢ Assume the client thread will use synchronized
blocks to obtain atomicity
public class SharedCoordinate { ... public synchronized void write(int newX, int newY) { x = newX; y = newY; }
public int readX() { return x; } // not synchronized public int readY() { return y; } // not synchronized}
SharedCoordinate point1 = new SharedCoordinate(0,0);
synchronized(point1) { SharedCoordinate point2 = new SharedCoordinate( point1.readX(), point1.readY());}
EEL 6897 14
Static Data
ā¢ Static data is shared between all objects created from the class
ā¢ In Java, classes themselves are also objects and there is a lock associated with the class
ā¢ This lock may be accessed by either labeling a static method with the synchronized modifier or by identifying the class's object in a synchronized block statement
ā¢ The latter can be obtained from the Object class associated with the object
ā¢ Note that this class-wide lock is not obtained when synchronizing on the object
EEL 6897 15
Static Data
class StaticSharedVariable { private static int shared; ... public int Read() { synchronized(StaticSharedVariable.class) { return shared; }; }
public synchronized static void Write(int I) { shared = I; }}
EEL 6897 16
Waiting and Notifying Iā¢ To obtain conditional synchronization requires the
methods provided in the predefined object class
public class Object { ...
public final void notify(); public final void notifyAll();
public final void wait() throws InterruptedException; public final void wait(long millis) throws InterruptedException; public final void wait(long millis, int nanos) throws InterruptedException; ...}
EEL 6897 17
Waiting and Notifying II
ā¢ These methods should be used only from within methods which hold the object lock
ā¢ If called without the lock, the unchecked exception IllegalMonitorStateException is thrown
ā¢ The wait method always blocks the calling thread and releases the lock associated with the object
EEL 6897 18
Important Notes
ā¢ The notify method wakes up one waiting thread; the one woken is not defined by the Java language
ā¢ notify does not release the lock; hence the woken thread must wait until it can obtain the lock before proceeding
ā¢ To wake up all waiting threads requires use of the notifyAll method
ā¢ If no thread is waiting, then notify and notifyAll have no effect
EEL 6897 19
Thread Interruption
ā¢ A waiting thread can also be awoken if it is interrupted by another thread
ā¢ In this case the InterruptedException is thrown (see later in the course)
EEL 6897 20
Condition Variables I
ā¢ There are no explicit condition variables in Java
ā¢ When a thread is awoken, it cannot assume that its condition is true, as all threads are potentially awoken irrespective of what conditions they were waiting on
ā¢ For some algorithms this limitation is not a problem, as the conditions under which tasks are waiting are mutually exclusive
ā¢ E.g., the bounded buffer traditionally has two condition variables: BufferNotFull and BufferNotEmpty
ā¢ If a thread is waiting for one condition, no other thread can be waiting for the other condition
ā¢ One would expect that the thread can assume that when it wakes, the buffer is in the appropriate state
EEL 6897 21
Condition Variables II
ā¢ This is not always the case; Java makes no guarantee that a thread woken from a wait will gain immediate access to lock
ā¢ Another thread could call the put method, find that the buffer has space and inserted data into the buffer
ā¢ When the woken thread eventually gains access to the lock, the buffer will again be full
ā¢ Hence, it is usually essential for threads to re-evaluate their guards
EEL 6897 22
Bounded Buffer I
public class BoundedBuffer { private int buffer[]; private int first; private int last; private int numberInBuffer = 0; private int size;
public BoundedBuffer(int length) { size = length; buffer = new int[size]; last = 0; first = 0; };
EEL 6897 23
Bounded Buffer II public synchronized void put(int item) throws InterruptedException { while (numberInBuffer == size) wait(); last = (last + 1) % size ; // % is modulus numberInBuffer++; buffer[last] = item; notifyAll(); };
public synchronized int get() throws InterruptedException { while (numberInBuffer == 0) wait(); first = (first + 1) % size ; // % is modulus numberInBuffer--; notifyAll(); return buffer[first]; };}
EEL 6897 24
Class Exercise
ā¢ How would you implement a semaphore using Java?
EEL 6897 25
Solution
EEL 6897 26
Summary Iā¢ Errors in communication and synchronization cause
working programs to suddenly suffer from deadlock or livelock
ā¢ The Java model revolves around controlled access to shared data using a monitor-like facility
ā¢ The monitor is represented as an object with synchronized methods and statements providing mutual exclusion
ā¢ Condition synchronization is given by the wait and notify method
ā¢ True monitor condition variables are not directly supported by the language and have to be programmed explicitly
EEL 6897 27
Further Reading and Exercises
ā¢ If you do not understand monitors then go to the library and find any operating systems book and read about them
ā¢ Do the Accessing Shared Data exercise