CSCI 6900: Design, Implementation, and Verification of Concurrent Software

CSCI 6900: Design, Implementation, and Verification of Concurrent Software Eileen Kraemer August 24th, 2010 The University of Georgia

Java Threads & Concurrency, continued • Liveness • Deadlock • Starvation and Livelock • Guarded Blocks • Immutable Objects • A Synchronized Class Example • A Strategy for Defining Immutable Objects • High Level Concurrency Objects • Lock Objects • Executors • Executor Interfaces • Thread Pools • Concurrent Collections • Atomic Variables

Immutable Objects • state cannot change after it is constructed. • useful in concurrent applications. • Since they cannot change state, they cannot be : • corrupted by thread interference • observed in an inconsistent state.

SynchronizedRGB • See code handout … • See any problems???

What if …. Thread 1: SynchronizedRGB color = new SynchronizedRGB(0, 0, 0, "Pitch Black"); ... //Statement 1 intmyColorInt = color.getRGB(); //Statement 2 String myColorNamecolor.getName(); Thread 2: //In between .. Color.set(someColor);

Solution for a mutable objects synchronized (color) { intmyColorInt = color.getRGB(); String myColorName = color.getName(); }

Immutable objects … • Don't provide "setter" methods — methods that modify fields or objects referred to by fields. • Make all fields final and private. • Don't allow subclasses to override methods. The simplest way to do this is to declare the class as final. A more sophisticated approach is to make the constructor private and construct instances in factory methods. • If the instance fields include references to mutable objects, don't allow those objects to be changed: • Don't provide methods that modify the mutable objects. • Don't share references to the mutable objects. Never store references to external, mutable objects passed to the constructor; if necessary, create copies, and store references to the copies. Similarly, create copies of your internal mutable objects when necessary to avoid returning the originals in your methods.

To make SynchronizedRGB immutable: • There are two setter methods in this class. The first one, set, arbitrarily transforms the object, and has no place in an immutable version of the class. The second one, invert, can be adapted by having it create a new object instead of modifying the existing one. • All fields are already private; they are further qualified as final. • The class itself is declared final. • Only one field refers to an object, and that object is itself immutable. Therefore, no safeguards against changing the state of "contained" mutable objects are necessary.

See modified class ….

High Level Concurrency Objects • Lock objects • Executors • Concurrent collections • Atomic variables

Lock objects • “synchronized” uses simple type of reentrant lock • Other locking idioms can be found in: • java.util.concurrent.locks • Basic interface: Lock • Only one thread can own at a time • Have associated Condition objects • Support a wait/notify mechanism • Special features • Can check if lock is available (tryLock) and then back out • lockInterruptibly – backs out if another thread sends interrupt before lock is acquired

New & improved Alphonse and Gaston • See Safelock example

Thursday … • Executors • Concurrent Collections • Atomic Variables

CSCI 6900: Design, Implementation, and Verification of Concurrent Software