Lecture 19: Composing Objects in Java

Transcription

1 COMP 150-CCP Concurrent Programming Lecture 19: Composing Objects in Java Dr. Richard S. Hall Concurrent programming April 1, 2008

2 Reference The content of this lecture is based on Chapter 4 of the Java Concurrency in Practice book by Brian Goetz.

3 Raising the Level The last few lectures have focused on low-level details of the Java memory model i.e., memory visibility guarantees It is important to understand these details to understand the issues However, these issues are somewhat overwhelming As mentioned in the last lecture, these issues can be simplified by using existing classes and/or various approaches This lecture will focus on how to structure classes to ensure their thread safety

4 Designing a Thread-Safe Class The design process for a thread-safe class should include these three basic elements

5 Designing a Thread-Safe Class The design process for a thread-safe class should include these three basic elements Identify the variables that form the object's state,

6 Designing a Thread-Safe Class The design process for a thread-safe class should include these three basic elements Identify the variables that form the object's state, Identify the invariants that constrain the state variables, and

7 Designing a Thread-Safe Class The design process for a thread-safe class should include these three basic elements Identify the variables that form the object's state, Identify the invariants that constrain the state variables, and Establish a policy for managing concurrent access to the object's state Encapsulation of state plays a key role

8 Determining Object State Consider the following class: public class Point { private int x, y; public Point(x, y) { this.x = x; this.y = y; public int getx() { return x; public void setx(int x) { this.x = x; public int gety() { return y; public void sety(int y) { this.y = y;

9 Determining Object State Consider the following class: public class Point { private int x, y; public Point(x, y) { this.x = x; What is the state of this this.y = y; class? public int getx() { return x; public void setx(int x) { this.x = x; public int gety() { return y; public void sety(int y) { this.y = y;

10 Determining Object State Consider the following class: public class Point { private int x, y; public Point(x, y) { this.x = x; this.y = y; public int getx() { return x; public void setx(int x) { this.x = x; public int gety() { return y; public void sety(int y) { this.y = y; The x and y member fields.

11 Determining Object State Consider the following class: public class Point { private int x, y; public Point(x, y) { this.x = x; this.y = y; public int getx() { return x; public void setx(int x) { this.x = x; public int gety() { return y; public void sety(int y) { this.y = y; Which invariants constrain the state?

12 Determining Object State Consider the following class: public class Point { private int x, y; public Point(x, y) { this.x = x; this.y = y; public int getx() { return x; public void setx(int x) { this.x = x; public int gety() { return y; public void sety(int y) { this.y = y; Difficult to say, but looking at this none, since there isn't an obvious relationship between x and y.

13 Determining Object State Consider the following class: public class Point { private int x, y; public Point(x, y) { this.x = x; So, how should we protect the state? this.y = y; public int getx() { return x; public void setx(int x) { this.x = x; public int gety() { return y; public void sety(int y) { this.y = y;

14 Determining Object State Consider the following class: public class Point { private int x, y; public Point(x, y) { this.x = x; Synchronize the state access methods. this.y = y; public synchronized int getx() { return x; public synchronized void setx(int x) { this.x = x; public synchronized int gety() { return y; public synchronized void sety(int y) { this.y = y;

15 Object State Constraints Object state values may have certain constraints or invariants placed on them, e.g., Multiple related variables must be changed together Certain state values may be invalid Certain state transitions may be invalid

16 Object State Constraints Object state values may have certain constraints or invariants placed on them, e.g., Multiple related variables must be changed together Certain state values may be invalid Certain state transitions may be invalid These types of constraints put additional synchronization and encapsulation requirements Depending on the constraints, the level of encapsulation can be adjusted You cannot ensure thread safety without understanding an object's invariants and postconditions

17 Object State Constraints Consider the following class: public class NumberRange { // INVARIANT: lower <= upper private long lower, upper; public synchronized void setlower(int i) { if (i > upper) throw new IllegalArgumentException( Invalid ); lower.set(i); public synchronized void setupper(int i) { if (i < lower) throw new IllegalArgumentException( Invalid ); upper.set(i); public synchronized boolean isinrange(int i) { return (i >= lower.get() && i <= upper.get());

18 Object State Constraints Consider the following class: public class NumberRange { // INVARIANT: lower <= upper private long lower, upper; What is the state? public synchronized void setlower(int i) { if (i > upper) throw new IllegalArgumentException( Invalid ); lower.set(i); public synchronized void setupper(int i) { if (i < lower) throw new IllegalArgumentException( Invalid ); upper.set(i); public synchronized boolean isinrange(int i) { return (i >= lower.get() && i <= upper.get());

19 Object State Constraints Consider the following class: public class NumberRange { // INVARIANT: lower <= upper private long lower, upper; The lower and upper fields. public synchronized void setlower(int i) { if (i > upper) throw new IllegalArgumentException( Invalid ); lower.set(i); public synchronized void setupper(int i) { if (i < lower) throw new IllegalArgumentException( Invalid ); upper.set(i); public synchronized boolean isinrange(int i) { return (i >= lower.get() && i <= upper.get());

20 Object State Constraints Consider the following class: public class NumberRange { // INVARIANT: lower <= upper private long lower, upper; Is the state properly protected? public synchronized void setlower(int i) { if (i > upper) throw new IllegalArgumentException( Invalid ); lower.set(i); public synchronized void setupper(int i) { if (i < lower) throw new IllegalArgumentException( Invalid ); upper.set(i); public synchronized boolean isinrange(int i) { return (i >= lower.get() && i <= upper.get());

21 Object State Constraints Consider the following class: public class NumberRange { // INVARIANT: lower <= upper private long lower, upper; Essentially, but what is wrong with this approach? public synchronized void setlower(int i) { if (i > upper) throw new IllegalArgumentException( Invalid ); lower.set(i); public synchronized void setupper(int i) { if (i < lower) throw new IllegalArgumentException( Invalid ); upper.set(i); public synchronized boolean isinrange(int i) { return (i >= lower.get() && i <= upper.get());

22 Object State Constraints Consider the following class: public class NumberRange { // INVARIANT: lower <= upper private long lower, upper; First, it has implicit protocol when changing both values to avoid an exception. public synchronized void setlower(int i) { if (i > upper) throw new IllegalArgumentException( Invalid ); lower.set(i); public synchronized void setupper(int i) { if (i < lower) throw new IllegalArgumentException( Invalid ); upper.set(i); public synchronized boolean isinrange(int i) { return (i >= lower.get() && i <= upper.get());

23 Object State Constraints Consider the following class: public class NumberRange { // INVARIANT: lower <= upper private long lower, upper; Even worse, another thread could be changing both values and we could interleave our values. public synchronized void setlower(int i) { if (i > upper) throw new IllegalArgumentException( Invalid ); lower.set(i); public synchronized void setupper(int i) { if (i < lower) throw new IllegalArgumentException( Invalid ); upper.set(i); public synchronized boolean isinrange(int i) { return (i >= lower.get() && i <= upper.get());

24 State Ownership Java's garbage collection allows us to be lazy about state ownership This is considerably different in C++, for example

25 State Ownership Java's garbage collection allows us to be lazy about state ownership This is considerably different in C++, for example State ownership is not embodied in the language It is an element of class design

26 State Ownership Java's garbage collection allows us to be lazy about state ownership This is considerably different in C++, for example State ownership is not embodied in the language It is an element of class design When you pass a reference into a method are you Transferring ownership? Engaging in a short-term loan? Joining a long-term joint ownership? Often ownership and encapsulation go hand-inhand, but not necessarily

27 State Ownership The owner of state gets to determine the locking protocol used to maintain integrity Ownership implies control, which is why we have to be careful about unintentionally publishing objects Despite garbage collection, it is import to think carefully and be explicit about ownership Forms of split ownership are also common Collection classes maintain a set of objects that are ultimately owned by client code Who provides the locking protocol in this case?

28 Using Non-Thread-Safe Classes Consider the following class: public class PersonSet private final Set<Person> myset = new HashSet<Person>(); public synchronized void addperson(person p) { myset.add(p); public synchronized boolean containsperson(person p) { return myset.contains(p);

29 Using Non-Thread-Safe Classes Consider the following class: HashSet is not thread safe, is PersonSet thread safe? public class PersonSet private final Set<Person> myset = new HashSet<Person>(); public synchronized void addperson(person p) { myset.add(p); public synchronized boolean containsperson(person p) { return myset.contains(p);

30 Using Non-Thread-Safe Classes Consider the following class: Yes, because all access to the HashSet is properly guarded. public class PersonSet private final Set<Person> myset = new HashSet<Person>(); public synchronized void addperson(person p) { myset.add(p); public synchronized boolean containsperson(person p) { return myset.contains(p);

31 Using Non-Thread-Safe Classes Consider the following class: What about Person objects? public class PersonSet private final Set<Person> myset = new HashSet<Person>(); public synchronized void addperson(person p) { myset.add(p); public synchronized boolean containsperson(person p) { return myset.contains(p);

32 Using Non-Thread-Safe Classes Consider the following class: If they are mutable then they will need to be thread safe too, but depends on ownership. public class PersonSet private final Set<Person> myset = new HashSet<Person>(); public synchronized void addperson(person p) { myset.add(p); public synchronized boolean containsperson(person p) { return myset.contains(p);

33 Instance Confinement Encapsulation simplifies making classes thread safe by promoting instance confinement Confines access, which makes it easier to ensure proper locking policy Simplest way to use non-thread-safe classes with multiple threads Important to not let confined instance escape Approach common in JRE e.g., Collections.synchronizedList uses Decorator pattern to confine ArrayList Wraps each method as synchronized and delegates to the confined instance

34 Java Monitor Pattern Instance confinement taken to the extreme leads to the Java monitor pattern Object encapsulates all mutable state and guards it with its intrinsic lock The primary benefit is simplicity Using object's intrinsic lock is just convention Any lock would suffice

35 Java Monitor Pattern Example Consider the following example: public class PrivateLock { private final Object mylock = new Widget widget; void somemethod() { synchronized(mylock) { // Access or modify the state of widget

36 Java Monitor Pattern Example Consider the following example: Is this class a proper monitor? public class PrivateLock { private final Object mylock = new Widget widget; void somemethod() { synchronized(mylock) { // Access or modify the state of widget

37 Java Monitor Pattern Example Consider the following example: Yes. Why might you want to use a private lock instead of the intrinsic lock? public class PrivateLock { private final Object mylock = new Widget widget; void somemethod() { synchronized(mylock) { // Access or modify the state of widget

38 Java Monitor Pattern Example Consider the following example: Disallows client code from participating in the synchronization policy. public class PrivateLock { private final Object mylock = new Widget widget; void somemethod() { synchronized(mylock) { // Access or modify the state of widget

39 Vehicle Tracker Example 1 Consider a vehicle tracking system where we want to be able to get vehicles positions in the rendering thread, such as Map<String, Point> locations = vehicles.getlocations(); for (String key : locations.keyset()) rendervehicle(key, locations.get(key));

40 Vehicle Tracker Example 1 Consider a vehicle tracking system where we want to be able to get vehicles positions in the rendering thread, such as Map<String, Point> locations = vehicles.getlocations(); for (String key : locations.keyset()) rendervehicle(key, locations.get(key)); And we have an updater thread that updates vehicle locations, such as void vehiclemoved(vehiclemovedevent evt) { Point loc = evt.getnewlocation(); vehicles.setlocation(evt.getvehicleid(), loc.x, loc.y);

41 Vehicle Tracker Example 1 We use the following mutable point class: public class MutablePoint { public int x, y; public MutablePoint() { x = 0; y = 0; public MutablePoint(MutablePoint p) { this.x = p.x; this.y = p.y;

42 Vehicle Tracker Example 1 Vehicle tracker class (1/2): public class MonitorVehicleTracker private final Map<String, MutablePoint> locations; public MonitorVehicleTracker(Map<String, MutablePoint> locations) { this.locations = deepcopy(locations); public synchronized Map<String, MutablePoint> getlocations() { return deepcopy(locations); public synchronized MutablePoint getlocation(string id) { MutablePoint loc = locations.get(id); return loc == null? null : new MutablePoint(loc); // Continued...

43 Vehicle Tracker Example 1 Vehicle tracker class (2/2): public synchronized void setlocation(string id, int x, int y) { MutablePoint loc = locations.get(id); if (loc == null) throw new IllegalArgumentException("No such ID: " + id); loc.x = x; loc.y = y; private static Map<String, MutablePoint> deepcopy( Map<String, MutablePoint> m) { Map<String, MutablePoint> result = new HashMap<String, MutablePoint>(); for (String id : m.keyset()) result.put(id, new MutablePoint(m.get(id))); return Collections.unmodifiableMap(result);

44 Vehicle Tracker Example 1 Vehicle tracker class (2/2): public synchronized void setlocation(string id, int x, int y) { MutablePoint loc = locations.get(id); if (loc == null) throw new IllegalArgumentException("No such ID: " + id); loc.x = x; loc.y = y; private static Map<String, MutablePoint> deepcopy( Map<String, MutablePoint> m) { Map<String, MutablePoint> result = new HashMap<String, MutablePoint>(); for (String id : m.keyset()) result.put(id, new MutablePoint(m.get(id))); return Collections.unmodifiableMap(result); How did this implementation achieve thread safety?

45 Vehicle Tracker Example 1 Vehicle tracker class (2/2): public synchronized void setlocation(string id, int x, int y) { MutablePoint loc = locations.get(id); if (loc == null) throw new IllegalArgumentException("No such ID: " + id); loc.x = x; loc.y = y; private static Map<String, MutablePoint> deepcopy( Map<String, MutablePoint> m) { Map<String, MutablePoint> result = new HashMap<String, MutablePoint>(); for (String id : m.keyset()) result.put(id, new MutablePoint(m.get(id))); return Collections.unmodifiableMap(result); By only returning copies of the mutable points.

46 Vehicle Tracker Example 1 Vehicle tracker class (2/2): public synchronized void setlocation(string id, int x, int y) { MutablePoint loc = locations.get(id); if (loc == null) throw new IllegalArgumentException("No such ID: " + id); loc.x = x; loc.y = y; private static Map<String, MutablePoint> deepcopy( Map<String, MutablePoint> m) { Map<String, MutablePoint> result = new HashMap<String, MutablePoint>(); for (String id : m.keyset()) result.put(id, new MutablePoint(m.get(id))); return Collections.unmodifiableMap(result); What are some consequences of returning copies?

47 Vehicle Tracker Example 1 Vehicle tracker class (2/2): public synchronized void setlocation(string id, int x, int y) { MutablePoint loc = locations.get(id); if (loc == null) throw new IllegalArgumentException("No such ID: " + id); loc.x = x; loc.y = y; private static Map<String, MutablePoint> deepcopy( Map<String, MutablePoint> m) { Map<String, MutablePoint> result = new HashMap<String, MutablePoint>(); for (String id : m.keyset()) result.put(id, new MutablePoint(m.get(id))); return Collections.unmodifiableMap(result); Potentially poorer performance...

48 Vehicle Tracker Example 1 Vehicle tracker class (2/2): public synchronized void setlocation(string id, int x, int y) { MutablePoint loc = locations.get(id); if (loc == null) throw new IllegalArgumentException("No such ID: " + id); loc.x = x; loc.y = y; private static Map<String, MutablePoint> deepcopy( Map<String, MutablePoint> m) { Map<String, MutablePoint> result = new HashMap<String, MutablePoint>(); for (String id : m.keyset()) result.put(id, new MutablePoint(m.get(id))); return Collections.unmodifiableMap(result); Also, returned information is potentially stale.

49 Delegating Thread Safety The Java monitor pattern is mostly useful useful for building thread-safe classes from scratch or to encapsulate non-thread-safe classes What happens if we are composing a class out of classes that are already thread safe? Do we need an additional layer of thread safety?

50 Delegating Thread Safety The Java monitor pattern is mostly useful useful for building thread-safe classes from scratch or to encapsulate non-thread-safe classes What happens if we are composing a class out of classes that are already thread safe? Do we need an additional layer of thread safety? Unfortunately, it depends We have seen examples where we do not, e.g, the counting factorizer using an AtomicLong We have seen example where we do, e.g., the caching factorizer using AtomicReferences

51 Vehicle Tracker Example 2 Assume we use this immutable public class Point { public final int x, y; public Point(int x, int y) { this.x = x; this.y = y;

52 Vehicle Tracker Example 2 New vehicle tracker class: public class DelegatingVehicleTracker { private final ConcurrentMap<String, Point> locations; private final Map<String, Point> unmodifiablemap; public DelegatingVehicleTracker(Map<String, Point> points) { locations = new ConcurrentHashMap<String, Point>(points); unmodifiablemap = Collections.unmodifiableMap(locations); public Map<String, Point> getlocations() { return unmodifiablemap; public Point getlocation(string id) { return locations.get(id); public void setlocation(string id, int x, int y) { if (locations.replace(id, new Point(x, y)) == null) throw new IllegalArgumentException("invalid id: " + id);

53 Vehicle Tracker Example 2 New vehicle tracker class: public class DelegatingVehicleTracker { private final ConcurrentMap<String, Point> locations; private final Map<String, Point> unmodifiablemap; public DelegatingVehicleTracker(Map<String, Point> points) { locations = new ConcurrentHashMap<String, Point>(points); unmodifiablemap = Collections.unmodifiableMap(locations); public Map<String, Point> getlocations() { return unmodifiablemap; public Point getlocation(string id) { return locations.get(id); Is this thread safe? public void setlocation(string id, int x, int y) { if (locations.replace(id, new Point(x, y)) == null) throw new IllegalArgumentException("invalid id: " + id);

54 Vehicle Tracker Example 2 New vehicle tracker class: public class DelegatingVehicleTracker { private final ConcurrentMap<String, Point> locations; private final Map<String, Point> unmodifiablemap; public DelegatingVehicleTracker(Map<String, Point> points) { locations = new ConcurrentHashMap<String, Point>(points); unmodifiablemap = Collections.unmodifiableMap(locations); public Map<String, Point> getlocations() { return unmodifiablemap; public Point getlocation(string id) { return locations.get(id); Yes, it delegates to its thread-safe state and has no explicit synchronization. public void setlocation(string id, int x, int y) { if (locations.replace(id, new Point(x, y)) == null) throw new IllegalArgumentException("invalid id: " + id);

55 Vehicle Tracker Example 2 New vehicle tracker class: public class DelegatingVehicleTracker { private final ConcurrentMap<String, Point> locations; private final Map<String, Point> unmodifiablemap; public DelegatingVehicleTracker(Map<String, Point> points) { locations = new ConcurrentHashMap<String, Point>(points); unmodifiablemap = Collections.unmodifiableMap(locations); public Map<String, Point> getlocations() { return unmodifiablemap; public Point getlocation(string id) { return locations.get(id); Is the behavior the same as the last version? public void setlocation(string id, int x, int y) { if (locations.replace(id, new Point(x, y)) == null) throw new IllegalArgumentException("invalid id: " + id);

56 Vehicle Tracker Example 2 New vehicle tracker class: public class DelegatingVehicleTracker { private final ConcurrentMap<String, Point> locations; private final Map<String, Point> unmodifiablemap; public DelegatingVehicleTracker(Map<String, Point> points) { locations = new ConcurrentHashMap<String, Point>(points); unmodifiablemap = Collections.unmodifiableMap(locations); public Map<String, Point> getlocations() { return unmodifiablemap; public Point getlocation(string id) { return locations.get(id); No, it returns a live view, rather than a snapshot. public void setlocation(string id, int x, int y) { if (locations.replace(id, new Point(x, y)) == null) throw new IllegalArgumentException("invalid id: " + id);

57 Delegating Thread Safety The previous example only had a single state variable, so it was easy to delegate thread safety It is possible to delegate thread safety to multiple state variables, but they must be independent No invariants expressed across multiple variables

58 Delegating Thread Safety Example Consider the following example public class VisualComponent { private final List<KeyListener> keylisteners = new CopyOnWriteArrayList<KeyListener>(); private final List<MouseListener> mouselisteners = new CopyOnWriteArrayList<MouseListener>(); public void addkeylistener(keylistener listener) { keylisteners.add(listener); public void addmouselistener(mouselistener listener) { mouselisteners.add(listener); public void removekeylistener(keylistener listener) { keylisteners.remove(listener); public void removemouselistener(mouselistener listener) { mouselisteners.remove(listener);

59 Delegating Thread Safety Example Consider the following example public class VisualComponent { private final List<KeyListener> keylisteners = new CopyOnWriteArrayList<KeyListener>(); private final List<MouseListener> mouselisteners = new CopyOnWriteArrayList<MouseListener>(); public void addkeylistener(keylistener listener) { keylisteners.add(listener); This is thread safe because the state variables are independent. public void addmouselistener(mouselistener listener) { mouselisteners.add(listener); public void removekeylistener(keylistener listener) { keylisteners.remove(listener); public void removemouselistener(mouselistener listener) { mouselisteners.remove(listener);

60 Delegating Thread Safety Example What about our number range example? public class NumberRange { // INVARIANT: lower <= upper private final AtomicInteger lower = new AtomicInteger(0); private final AtomicInteger upper = new AtomicInteger(0); public void setlower(int i) { if (i > upper.get()) throw new IllegalArgumentException( "can't set lower to " + i + " > upper"); lower.set(i); public void setupper(int i) { if (i < lower.get()) throw new IllegalArgumentException( "can't set upper to " + i + " < lower"); upper.set(i); public boolean isinrange(int i) { return (i >= lower.get() && i <= upper.get());

61 Delegating Thread Safety Example What about our number range example? public class NumberRange { // INVARIANT: lower <= upper private final AtomicInteger lower = new AtomicInteger(0); private final AtomicInteger upper = new AtomicInteger(0); public void setlower(int i) { if (i > upper.get()) throw new IllegalArgumentException( "can't set lower to " + i + " > upper"); lower.set(i); public void setupper(int i) { if (i < lower.get()) throw new IllegalArgumentException( "can't set upper to " + i + " < lower"); upper.set(i); public boolean isinrange(int i) { return (i >= lower.get() && i <= upper.get()); It didn't work in our earlier version and it doesn't work with delegation either.

62 Publishing Underlying State Values Is it possible to publish underlying thread-safe state variables? Again, it depends If the possible values or transitions need to be constrained, then probably not If the state is completely self-contained in the threadsafe state variable, then maybe It is probably best to avoid publishing them no matter what, but think long and hard before you do

63 Extending Thread-Safe Classes How do we go about adding functionality to an existing thread-safe class? For example, assume that we want to add a put-ifabsent method on a list collection class The least fragile way is to modify the source code directly Here you will need to understand the class' synchronization policy The benefit is that the synchronization policy is still all contained in a single class Another approach is to create a subclass...

64 Extending Thread-Safe Classes Creating a subclass public class BetterVector<E> extends Vector<E> { public synchronized boolean putifabsent(e x) { boolean absent =!contains(x); if (absent) add(x); return absent;

65 Extending Thread-Safe Classes Creating a subclass public class BetterVector<E> extends Vector<E> { public synchronized boolean putifabsent(e x) { boolean absent =!contains(x); if (absent) add(x); return absent; Still need to understand the synchronization policy...

66 Extending Thread-Safe Classes Creating a subclass public class BetterVector<E> extends Vector<E> { public synchronized boolean putifabsent(e x) { boolean absent =!contains(x); if (absent) add(x); return absent; This is more fragile than modifying the source directly, why?

67 Extending Thread-Safe Classes Creating a subclass public class BetterVector<E> extends Vector<E> { public synchronized boolean putifabsent(e x) { boolean absent =!contains(x); if (absent) add(x); return absent; Synchronization policy is spread across multiple files. If the policy changes, our class will break.

68 Extending Thread-Safe Classes Client-side locking is another approach... public class ListHelper<E> { public List<E> list = Collections.synchronizedList(new ArrayList<E>());... public synchronized boolean putifabsent(e x) { boolean absent =!list.contains(x); if (absent) list.add(x); return absent;

69 Extending Thread-Safe Classes Client-side locking is another approach... public class ListHelper<E> { public List<E> list = Collections.synchronizedList(new ArrayList<E>());... public synchronized boolean putifabsent(e x) { boolean absent =!list.contains(x); if (absent) list.add(x); return absent; Is this good?

70 Extending Thread-Safe Classes Client-side locking is another approach... public class ListHelper<E> { public List<E> list = Collections.synchronizedList(new ArrayList<E>());... public synchronized boolean putifabsent(e x) { boolean absent =!list.contains(x); if (absent) list.add(x); return absent; No, it is not using the correct lock.

71 Extending Thread-Safe Classes Client-side locking is another approach... public class ListHelper<E> { public List<E> list = Collections.synchronizedList(new ArrayList<E>());... public boolean putifabsent(e x) { synchronized (list) { boolean absent =!list.contains(x); if (absent) list.add(x); return absent; Again, we need to understand the synchronization policy.

72 Extending Thread-Safe Classes Composition is another approach... public class ImprovedList<T> implements List<T> { private final List<T> list; public ImprovedList(List<T> list) { this.list = list; public synchronized boolean putifabsent(t x) { boolean contains = list.contains(x); if (contains) list.add(x); return!contains; public synchronized void clear() { list.clear(); //... similarly delegate other List methods

73 Extending Thread-Safe Classes Composition is another approach... public class ImprovedList<T> implements List<T> { private final List<T> list; public ImprovedList(List<T> list) { this.list = list; Is this thread safe? public synchronized boolean putifabsent(t x) { boolean contains = list.contains(x); if (contains) list.add(x); return!contains; public synchronized void clear() { list.clear(); //... similarly delegate other List methods

74 Extending Thread-Safe Classes Composition is another approach... public class ImprovedList<T> implements List<T> { private final List<T> list; public ImprovedList(List<T> list) { this.list = list; Yes. Why is it less fragile? public synchronized boolean putifabsent(t x) { boolean contains = list.contains(x); if (contains) list.add(x); return!contains; public synchronized void clear() { list.clear(); //... similarly delegate other List methods

75 Extending Thread-Safe Classes Composition is another approach... public class ImprovedList<T> implements List<T> { private final List<T> list; public ImprovedList(List<T> list) { this.list = list; Because it defines its own synchronization policy. public synchronized boolean putifabsent(t x) { boolean contains = list.contains(x); if (contains) list.add(x); return!contains; public synchronized void clear() { list.clear(); //... similarly delegate other List methods

76 Extending Thread-Safe Classes Composition is another approach... public class ImprovedList<T> implements List<T> { private final List<T> list; public ImprovedList(List<T> list) { this.list = list; What is the state ownership assumption? public synchronized boolean putifabsent(t x) { boolean contains = list.contains(x); if (contains) list.add(x); return!contains; public synchronized void clear() { list.clear(); //... similarly delegate other List methods

77 Extending Thread-Safe Classes Composition is another approach... public class ImprovedList<T> implements List<T> { private final List<T> list; public ImprovedList(List<T> list) { this.list = list; It owns the passed in list. public synchronized boolean putifabsent(t x) { boolean contains = list.contains(x); if (contains) list.add(x); return!contains; public synchronized void clear() { list.clear(); //... similarly delegate other List methods

78 Documentation As has been shown in these slides, it is very important to document the synchronization policy For maintainers For clients