Concurrency

An open call is a method invocation made outside of a synchronized region.

Benefits:

• Prevents deadlocks by avoiding nested lock acquisition
• Increases concurrency by minimizing the duration locks are held
• Allows other threads to access shared resources during potentially long operations
• Prevents reentrant locking issues with callbacks

Implementation pattern:

1. Acquire lock
2. Examine/copy shared data as quickly as possible
3. Release lock
4. Perform time-consuming operations or calls to untrusted code without holding the lock

This is a fundamental principle for achieving high-performance thread-safe code.

Without synchronization, one thread's changes might not be visible to other threads. Even if operations are atomically readable/writable, synchronization is required for:

1. Visibility guarantee: Ensuring thread A's writes are visible to thread B
2. Memory model compliance: Java's memory model requires synchronization for reliable inter-thread communication

This can lead to:

• Liveness failures (program fails to progress)
• Safety failures (program computes incorrect results)
• Intermittent and timing-dependent bugs that vary across JVMs

Example: A boolean flag used for thread termination may never be seen by the thread meant to stop, causing an infinite loop.

volatile only guarantees visibility of the most recently written value, but does not provide atomicity for compound operations.

When incrementing (counter++):

1. The operation requires multiple steps: read, increment, write
2. These steps are not performed as a single atomic unit
3. Thread interleaving can cause lost updates

Example problem:

private static volatile int counter = 0; // BROKEN
public static int incrementAndGet() {
    return counter++; // NOT ATOMIC! Read and write are separate operations
}

Two threads could both read 0, increment to 1, and both write 1, causing one increment to be lost.

Proper solutions:

• Use synchronized methods/blocks
• Use atomic classes: AtomicInteger, AtomicLong, etc.

private static final AtomicInteger counter = new AtomicInteger(0);
public static int incrementAndGet() {
    return counter.getAndIncrement(); // Atomic operation
}

Effectively immutable objects:

• Are mutable objects that are never modified after initialization and safe publication
• Behave like immutable objects as long as references to them aren't published until construction is complete

Benefits:

1. Thread safety without synchronization: Once safely published, can be accessed without locking
2. Performance improvements: Reduced synchronization overhead
3. Simplified reasoning: Can be treated like immutable objects in concurrent code

Implementation pattern:

1. Fully initialize the object in its constructor
2. Don't leak the this reference during construction
3. Safely publish the reference to other threads
4. Never modify the object after publication

Example:

public class EffectivelyImmutable {
    private final List<String> data; // Note: List itself is mutable
    
    public EffectivelyImmutable(Collection<String> initial) {
        // Make defensive copy to ensure encapsulation
        this.data = new ArrayList<>(initial);
    }
    
    // Only provide non-modifying access methods
    public boolean contains(String s) {
        return data.contains(s);
    }
    
    public int size() {
        return data.size();
    }
    
    // No methods that would modify data
}

Once safely published, this object can be freely shared across threads without additional synchronization.

Standard wait method idiom:

// The standard idiom for using the wait method
synchronized (obj) {
    while (<condition does not hold>)
        obj.wait(); // Releases lock, and reacquires on wakeup
    // Perform action appropriate to condition
}

Why wait must be used in a loop:

1. Testing before waiting (protects liveness):

   • If condition already holds, skips unnecessary waiting
   • Prevents deadlock if notify was already called before waiting
   • No guarantee the thread will ever wake if notify happened earlier

2. Testing after waiting (protects safety):

   • Thread might wake up when condition still doesn't hold
   • Acting on the expectation that condition is true could corrupt invariants

Consequences of not using a loop:

• Potential deadlocks (thread might never wake)
• Race conditions (condition might change between notify and wakeup)
• Corruption of program state by proceeding when condition is false
• Vulnerability to spurious wakeups (threads can wake without notification)

Reasons a thread might wake when condition doesn't hold:

• Another thread changed state between notification and wakeup
• Accidental/malicious notifications on publicly accessible objects
• Overly "generous" notifications (notifyAll waking all threads)
• Spurious wakeups (rare but possible JVM behavior)

notify vs. notifyAll:

| notify | notifyAll | |--------|-----------| | Wakes a single waiting thread | Wakes all waiting threads | | More efficient (fewer thread wakeups) | Less efficient (unnecessary wakeups) | | Risk of leaving intended recipients waiting | Guaranteed to wake all necessary threads | | Requires careful reasoning about wait-sets | Conservative and always correct |

When it's safe to use notify (optimization conditions):

• All threads in the wait-set are waiting for the exact same condition
• Only one thread at a time can benefit from the condition becoming true
• You have complete control over all code that could wait on the object

Risks introduced by using notify:

• "Notification stealing" - an unintended thread receives the notification
• Critical notifications might be "swallowed" by unrelated threads
• If conditions change, notify might wake the wrong thread
• In public/accessible objects, malicious code could add waits that intercept notifications

Best Practice: Use notifyAll by default as a safer approach. Only use notify as a deliberate optimization after careful analysis of all possible waiter threads and their conditions.

Example of notify risk:

// Thread A and B wait on condition X
// Thread C waits on condition Y
// All wait on the same object
synchronized(obj) {
    // If we notify() when X becomes true
    // Thread C might wake instead of A or B
    // A and B might never wake
}

System.nanoTime() vs System.currentTimeMillis() for interval timing:

| System.nanoTime() | System.currentTimeMillis() | |-------------------|----------------------------| | Measures elapsed time (monotonic clock) | Measures wall-clock time | | Not affected by system clock changes | Affected by time zone changes, NTP adjustments, daylight savings | | Higher precision (nanosecond) | Lower precision (millisecond) | | Only meaningful for interval measurements | Can be used for timestamps and intervals | | Cannot be used to determine actual time of day | Reflects actual time of day |

Implications for benchmarking:

• Accuracy: System.nanoTime() provides more accurate measurements of elapsed time
• Stability: Not subject to sudden jumps if system time is adjusted
• Precision: Up to nanosecond precision (platform dependent)
• Consistency: Gives consistent results even during system time changes
• Monotonic guarantee: Always increases, never goes backward

Practical consequences:

• Benchmark results could be completely invalid if currentTimeMillis() is used and system time changes during measurement
• Manual time adjustments or NTP synchronization could cause artificial speedups or slowdowns in timings
• Millisecond precision may not be sufficient for micro-benchmarks of fast operations

Best practice:

// Correct timing approach
long startTime = System.nanoTime();
performOperation();
long elapsedNanos = System.nanoTime() - startTime;

For serious benchmarking, specialized frameworks like JMH (Java Microbenchmark Harness) should be used to account for JIT compilation, warm-up effects, and other complexities.

For primitive fields in lazy initialization:

1. The null check becomes a comparison against 0 (default value for numerical primitives)

   // Instead of checking against null:
   if (numericField == 0) // For primitives

2. For primitives other than long/double that can tolerate repeated initialization, you can use the racy single-check idiom (removing volatile)

3. Primitive initialization must handle the ambiguity that the default value (0) might be a valid computed value, unlike reference fields where null clearly indicates uninitialized state

4. Atomic operations and memory barriers work differently for primitives vs. references, requiring special attention to memory consistency effects

This creates additional complexity when adapting reference-based idioms to primitive fields.

The key requirement is: ensure that the average number of runnable threads is not significantly greater than the number of processors.

When this requirement is met:

• The thread scheduler has little choice but to run all runnable threads
• Program behavior varies minimally across different scheduling policies
• Performance remains consistent across systems
• Resource utilization is optimized

Practical implementation techniques:

1. Have threads do useful work, then wait for more work (don't idle in runnable state)
2. Size thread pools appropriately based on available processors
3. Keep tasks short but not too short (to avoid dispatching overhead)
4. Use proper blocking mechanisms instead of busy-waiting
5. Design thread interactions to minimize contention

Note that runnable threads ≠ total threads. Blocked/waiting threads don't count toward this limit.

The double-check idiom is a thread-safe pattern for lazy initialization that minimizes synchronization overhead:

Core Implementation:

private volatile FieldType field;

private FieldType getField() {
    FieldType result = field;  // Local variable optimization
    if (result == null) {      // First check (no locking)
        synchronized(this) {
            result = field;    // Re-read after acquiring lock
            if (field == null) // Second check (with locking)
                field = result = computeFieldValue();
        }
    }
    return result;
}

Key Requirements:

1. Volatile declaration: Absolutely critical - ensures visibility of changes across threads and prevents other threads from seeing partially initialized objects
2. Double checking: Checks nullity twice - first without locking (for performance), then with locking (for safety)
3. Synchronized block: Ensures only one thread initializes the field

Local Variable Optimization:

• Stores field value in local variable result
• Ensures field is read only once in the common already-initialized case
• Provides ~1.4x performance improvement over versions without the local variable
• Considered more elegant and aligned with low-level concurrent programming standards

Use Cases:

Used when lazy initialization is needed for performance on instance fields with high initialization cost but infrequent access.