Concurrency

Deadlock scenario:

1. Main thread holds the lock on observers while executing notifyElementAdded
2. Main thread calls the observer's added method
3. Observer spawns a background thread that calls removeObserver
4. Background thread attempts to acquire the lock on observers
5. Background thread cannot proceed because main thread holds the lock
6. Main thread waits for background thread to complete, creating a circular wait

This demonstrates how using a separate thread to modify a synchronized collection can lead to deadlock, even when trying to avoid ConcurrentModificationException.

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.

State-dependent modify operations are methods that combine multiple collection operations into a single atomic action.

Key characteristics:

• Perform checks and updates in a single atomic operation
• Prevent race conditions between checking a condition and acting on it
• Added to collections in java.util.concurrent and later to standard collections via default methods

Example operations:

// Adds key-value only if key doesn't exist, returns previous or null
map.putIfAbsent(key, value);

// Removes entry only if key maps to specific value
map.remove(key, value);

// Replaces value only if key maps to specific old value
map.replace(key, oldValue, newValue);

Solve problems like:

// Non-atomic approach (race condition vulnerable)
if (!map.containsKey(key))
    map.put(key, value);  // Race condition possible here

// Atomic approach (thread-safe)
map.putIfAbsent(key, value);

These operations eliminate the need for external synchronization while maintaining thread safety.

CountDownLatch is a synchronizer that:

• Acts as a one-time gate that remains closed until a count reaches zero
• Allows one or more threads to wait until a set of operations completes
• Is non-reusable (once count reaches zero, it cannot be reset)

Example usage to coordinate concurrent execution timing:

// Time the execution of an action with multiple threads
public static long time(Executor executor, int concurrency, 
                        Runnable action) throws InterruptedException {
    CountDownLatch ready = new CountDownLatch(concurrency);
    CountDownLatch start = new CountDownLatch(1);
    CountDownLatch done = new CountDownLatch(concurrency);
    
    for (int i = 0; i < concurrency; i++) {
        executor.execute(() -> {
            // Signal ready and wait for start signal
            ready.countDown();
            try {
                start.await(); // Wait until all threads ready
                
                action.run();  // Perform the action
                
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            } finally {
                done.countDown(); // Signal completion
            }
        });
    }
    
    ready.await();     // Wait for all workers to be ready
    long startNanos = System.nanoTime();
    start.countDown(); // Start all workers simultaneously 
    done.await();      // Wait for all workers to finish
    return System.nanoTime() - startNanos;
}

This pattern ensures all threads start simultaneously and accurately measures their total execution time.

The most dangerous error is believing that atomic operations don't require synchronization for inter-thread visibility.

Many programmers incorrectly think:

• Reading/writing atomic variables (int, boolean, reference) is automatically visible across threads
• Synchronization is only needed for compound operations or to maintain invariants
• Atomic operations are guaranteed to be seen by other threads without synchronization

The critical misunderstanding:

• Java guarantees that reads/writes of most variables are atomic (except long/double)
• BUT atomicity does not guarantee visibility across threads
• Without synchronization or volatile, there is no guarantee when (if ever) one thread will see another thread's writes

This leads to subtle, non-deterministic bugs that:

• May appear to work on some systems but fail on others
• Might work under low load but fail under stress
• Can be affected by seemingly unrelated code changes
• Are extremely difficult to reproduce and debug

Example of the dangerous pattern:

// BROKEN - may never terminate
public class StopThread {
    private static boolean stopRequested; // NOT volatile or synchronized
    
    public static void main(String[] args) throws InterruptedException {
        Thread backgroundThread = new Thread(() -> {
            int i = 0;
            while (!stopRequested) // May never see stopRequested change to true
                i++;
        });
        backgroundThread.start();
        
        TimeUnit.SECONDS.sleep(1);
        stopRequested = true; // This write may not be visible to the background thread
    }
}

Always use proper synchronization (synchronized or volatile) for inter-thread communication, even for atomic operations.

The Lazy Initialization Holder Class idiom is a thread-safe pattern for initializing static fields:

// Lazy initialization holder class idiom for static fields
private static class FieldHolder {
    static final FieldType field = computeFieldValue();
}

private static FieldType getField() { 
    return FieldHolder.field; 
}

When to use:

• Only for static field lazy initialization
• When performance optimization is needed
• To break initialization circularities

Why it's efficient:

• Exploits JVM's class initialization guarantees (JLS 12.4.1)
• No explicit synchronization in the access method
• FieldHolder class is only initialized when first accessed
• After initialization, field access has no synchronization overhead
• JVM handles synchronization during class initialization internally
• The VM typically patches code after initialization to avoid synchronization on subsequent accesses

This idiom is considered the most elegant approach for lazy initialization of static fields as it combines thread safety with minimal performance impact.

Thread Safety Documentation Requirements:

1. Class-level documentation:

   • Clear statement of thread safety level (immutable, unconditionally thread-safe, etc.)
   • Should appear in the class's Javadoc comment
   • Must be explicit - don't rely on the synchronized modifier (which is an implementation detail)

2. For conditionally thread-safe classes:

   • Identify which method sequences require external synchronization
   • Specify which lock to acquire when executing these sequences
   • Document if the lock is something other than the instance itself

3. For methods with special thread safety:

   • Include thread safety details in method-level documentation
   • Particularly important for methods that deviate from class's overall thread safety

4. For static factories:

   • Document thread safety of returned objects
   • Example: Collections.synchronizedMap() documents synchronization requirements for iterators

5. For thread-safe collections with iterators:

   • Explicitly state synchronization requirements for iteration
   • Include code examples showing proper synchronization

Example Documentation:

/**
 * This class is thread-safe. All public methods are
 * synchronized internally.
 */
public class ThreadSafeCounter {
    // Implementation...
}

/**
 * This class is conditionally thread-safe. Methods that
 * modify the internal state are thread-safe, but iteration
 * requires external synchronization on the instance.
 */
public class ConditionalCollection<E> {
    /**
     * Returns an iterator over elements. The iterator is not
     * thread-safe and the calling code must synchronize on 
     * this collection instance when using the iterator.
     */
    public Iterator<E> iterator() {
        // Implementation...
    }
}

The proper way to handle InterruptedException in worker threads:

try {
    // Code that might be interrupted
    startSignal.await();
    performWork();
} catch (InterruptedException e) {
    // Reassert the interrupt
    Thread.currentThread().interrupt();
    // Return from the current method or task
    return;
}

Key elements:

1. Catch InterruptedException explicitly
2. Reassert the interrupt using Thread.currentThread().interrupt()
3. Exit the current method or task promptly

Why this pattern is important:

• Preserves interruption status: Without reasserting, the interrupted status would be lost
• Respects thread control: Allows the executor or thread manager to handle the interrupt appropriately
• Prevents "interrupt swallowing": The common bug of catching InterruptedException and doing nothing
• Enables cancellation: Makes worker threads responsive to cancellation requests
• Facilitates clean shutdown: Supports orderly application shutdown

In concurrent timing frameworks:

• Allows the executor to clean up resources if timing is externally cancelled
• Prevents hung threads if the framework itself is interrupted
• Maintains the guarantee that workers will complete or be cleanly terminated
• Enables the framework to work properly with time-limited executors
• Preserves interrupt handling capability up the call chain

This is an example of cooperative interruption handling, a critical pattern for robust concurrent applications.

Factors determining lazy initialization benefit/harm:

1. Initialization frequency ratio:

   • What fraction of field instances eventually need initialization?
   • High percentage → lazy initialization likely harmful (paying overhead but getting little benefit)
   • Low percentage → lazy initialization potentially beneficial

2. Initialization cost:

   • How expensive is it to initialize the field?
   • High cost → lazy initialization more beneficial
   • Low cost → overhead might exceed benefits

3. Access frequency:

   • How often is the field accessed after initialization?
   • Frequent access → overhead on each access might accumulate
   • Rare access → total overhead remains low

4. Thread contention:

   • How many threads might concurrently initialize the field?
   • High contention → synchronization costs increase
   • Low contention → synchronization overhead minimal

**When to

Busy-waiting Problems in Concurrent Applications:

1. Resource Consumption Issues:

   • CPU overutilization: Continuously consumes CPU cycles checking conditions
   • Reduced system throughput: Decreases useful work other threads can accomplish
   • Poor scalability: Performance degrades dramatically as thread count increases (~10x worse with 1,000 threads)

2. Implementation Problems: The SlowCountDownLatch example demonstrates this:

   public void await() {
       while (true) {          // Keeps thread unnecessarily RUNNABLE
           synchronized(this) { // Creates lock contention
               if (count == 0)
                   return;
           }
       }
   }

3. Concurrency Inefficiencies:

   • Excessive contention: Threads repeatedly acquire and release locks
   • Increased context switching: OS must frequently switch between competing threads
   • Scheduler dependency: Makes program vulnerable to thread scheduler variations
   • Lock thrashing: Synchronization overhead from constant lock acquisition/release

4. Proper Alternative Approach:

   • Use wait/notify mechanism or java.util.concurrent classes
   • Make waiting threads non-runnable until needed
   • Release CPU resources to other threads
   • Implement efficient signaling when conditions change
   • Reduce synchronization overhead with proper blocking mechanisms