CSC 480 - Multiprocessor Programming, Spring, 2012Outline for Chapter 4 – Composing Objects – thread-safe object-oriented composition,

Dr. Dale E. Parson, week 4

Composing Objects

• Composing a class using only thread-safe classes does not make that class thread-safe.

• Design of a thread-safe class should include these three basic elements.

• Identify the variables that form an object’s state.• Identify the invariants that constrain the state variables.• Establish a policy for managing concurrent access to the

object’s state.• (Four: Document and communicate that policy.)

» See Listing 4.1.

Invariants and postconditions

• You cannot ensure thread safety without understanding an object’s invariants and postconditions. Constraints on the valid values or state transitions for state variables can create atomicity and encapsulation requirements.

• Encapsulating data within an object confines access to the data to the object’s methods, making it easier to ensure that the data is always accessed with the appropriate lock held. (instance confinement)

• Confined objects must not escape their intended scope.» See Listing 4.2.

Confinement

• Confinement makes it easier to build thread-safe classes because a class that confines its state can be analyzed for thread safety without having to examine the whole program.

• This observation also holds for single-threaded encapsulation. For example, letting a Map that has a very specific interpretation inside an object escape from that object, leaves it open for accidental mutation or other mishandling in client code.

• Two solutions are 1) To publish a clone of the Map that does not contaminate “the golden copy,” or 2) To create an immutable Map class and publish objects of that class.

Delegating thread safety

• A class may be able to delegate thread safety to thread-safe data member objects.

• If their interrelated mutation requires atomicity, then non-atomic access or publication of thread-safe members is not in itself thread-safe.

• See java.util.Collections for thread-safe adapters for non-thread-safe containers.

• unmodifiable* adapters create “final” views of collections. Watch out for UnsupportedOperationException!

• synchronized* adapters create views whose operations are locked. This approach is “brute force” compared to concurrent collections.

• See java.util.concurrent. See Listing 4.7.

Independent vs. interdependent state variables

• If a class is composed of multiple independent thread-safe state variables and has no operations that have any invalid state transitions, then it can delegate thread safety to the underlying state variables.

• If a state variable is thread-safe, does not participate in any invariants that constrain its value, and has not prohibited state transitions for any of its operations, then it can safely be published.

Adding functionality to existing thread-safe classes

• Subclassing is more fragile than adding code directly to a class, because synchronization of one object becomes distributed over multiple, separately maintain source files. (the yo-yo!)

• Private becomes protected. Changes in a bass class synchronization policy require reworking the subclass.

• Client-side locking can be difficult for more than trivial synchronization requirements.

• Composition is the least fragile approach because it encapsulates the synchronization policy in 1 class.

• See Listings 4.13 through 4.16.

Documentation

• Document a class’s thread safety guarantees for its clients; document its synchronization policy for its maintainers.

• Each use of synchronized, volatile, or any thread-safe class (and some uses of final and private!) reflects a synchronization policy defining a strategy for ensuring the integrity of data in the face of concurrent access.

• Use annotations from Appendix A consistently.• We will go over A Refactoring Approach to Parallelism, Danny Dig,

from IEEE Software from 2011 28(1) in class. The three categories of refactoring apply to Object Re-Composition.