1. More on Thread Safety
CSE451
Andrew Whitaker

2. Safety Rule #1 All shared, mutable state must be properly synchronized
Usually with a synchronized block or method

3. Rule #2 Compound actions must be protected by a single lock
Often, we talk about protecting an invariant with a single lock
e.g., aspect ratio remains fixed

4. Why Not Make Every Method Synchronized?
Synchronization has a performance cost
Each lock access is a cache miss
Synchronization limits parallelism
Rampant synchronization leads to deadlock
Amount of
synchronization
Available
parallelism

5. Safety Rule #1, Revised
All shared, mutable state must be properly synchronized
Usually with a synchronized block or method
Corollaries:
Do not synchronize for non-shared state
Accessed by a single thread
Do not synchronize on immutable state

6. This is unnecessary! No need to synchronize on non-shared state.
public class Foo {
public int addSix(int arg) {
synchronized (this) { // grab “this” lock
arg += 6;
} // release “this” lock
return arg; }
This is unnecessary!
No need to synchronize
on non-shared state.

7. Immutable state does not require synchronization!
// Thread-safe
public class Integer {
private final int x;
public Integer(int arg) {
this.x = arg; }
// hold “this” lock during entire method
public synchronized int get() { // hold “this”
return x;

8. Thread-safe Objects aString is thread-safe for any run method
public class Bar extends Thread {
private final String aString = “Hello”;
public void run() {
// .. Stuff in here… }
aString is thread-safe for any run method
The reference is immutable (final)
The String class is immutable

9. Concurrent State in Java
Immutable
Private, Mutable
Shared, Mutable
Strings
String
StringBuilder
StringBuffer
Lists
Collections.unmodifableList
ArrayList, LinkedList
Vector
Methods are not synchronized
All methods are synchronized

10. Documentation Diving: Java.util.ArrayList
Note that this implementation is not synchronized. If multiple threads access an ArrayList instance concurrently, and at least one of the threads modifies the list structurally, it must be synchronized externally. This is typically accomplished by synchronizing on some object that naturally encapsulates the list. If no such object exists, the list should be "wrapped" using the Collections.synchronizedList method.

11. Be Careful with Thread-safe Data Structures
public class MyClass extends Thread {
// Always thread-safe
private static final Vector<String> someStrings =
new Vector<String>();
// Not necessarily thread safe: StringBuilder is mutable
private static final Vector<StringBuilder> someMoreStrings =
new Vector<StringBuilder>();
public void run () {
// do something with the lists of strings… }
All reachable mutable state must be synchronized

12. Using Non-Thread-Safe Objects with Threads
public class MyClass extends Thread {
// This data structure is not thread-safe
private static final List<String> someStrings =
new ArrayList<String>();
public void run () {
// But, that’s OK if all accesses are
// synchronized on a single lock
synchronized(someStrings) {
someStrings.add(“fubar”); }

13. Example from Project #1
Do the execcounts counters require synchronized access?
Yes:
The counters are shared across multiple processes/threads
The counters are mutable
Solution: atomic variables
See Linux /include/asm-i386/atomic.h

14. Another Example: AspectRatio

15. Linked List Example