Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "1 CSCI 6900: Design, Implementation, and Verification of Concurrent Software Eileen Kraemer August 24 th, 2010 The University of Georgia."— Presentation transcript:

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

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

3 3 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.

4 4 SynchronizedRGB  See code handout …  See any problems???

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

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

7 7 Immutable objects … 1.Don't provide "setter" methods — methods that modify fields or objects referred to by fields. 2.Make all fields final and private. 3.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. 4.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.

8 8 To make SynchronizedRGB immutable: 1.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. 2.All fields are already private; they are further qualified as final. 3.The class itself is declared final. 4.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.

9 9 See modified class ….

10 10 High Level Concurrency Objects  Lock objects  Executors  Concurrent collections  Atomic variables

11 11 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

12 12 New & improved Alphonse and Gaston  See Safelock example

13 13 Thursday …  Executors  Concurrent Collections  Atomic Variables


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

Similar presentations


Ads by Google