20.3. Happens-Before Relationship

The JMM defines happens-before rules that govern visibility and ordering:

The Java Memory Model (JMM) has specific rules known as happens-before rules. These rules determine when operations in one thread become visible to another thread. They are essential for ensuring proper synchronization in Java programs, allowing developers to reason about the visibility of shared data across multiple threads.

Imagine two people working on a project in separate rooms. For them to stay updated, they must rely on specific signals indicating that one has completed a task before the other can view or build upon that work. The happens-before rules act like those signals, ensuring that one person's completed work is effectively communicated to the other.

This rule states that any action that occurs in a thread before it calls Thread.start() is guaranteed to be visible to the new thread once it starts running. This means, for example, that any changes to shared variables made by the previous thread will be seen by the newly started thread immediately after it begins execution.

Think of a baton race where the runner preparing the baton passes it to the next runner. Only once the first runner has completed their distance and hands off the baton (insuring the second runner knows the new position) can the next runner begin. Similarly, this happens-before rule ensures that the new thread has all the necessary information before it begins.

When one thread calls Thread.join() on another thread, it guarantees that all actions that occurred in the completed thread are visible to the calling thread after the join. This is important for ensuring that if one thread depends on the results or side effects of another, it will not proceed until those are fully completed and visible.

Consider a classroom scenario where one student waits for another to finish presenting before they can share their thoughts. The presentation (action) must be completed and inputs noted before the waiting student can respond. This mimics how one thread waits for another to finish before getting access to the updated information.

This rule indicates that if a thread unlocks a monitor, any actions that happened before the unlock in that thread will be visible to any subsequent thread that locks the same monitor. This is crucial for safely sharing resources synchronized through monitor locks.

Imagine a shared resource like a conference room. When one person leaves (unlocks the room), all the decisions made during their time in the room can be discussed the next time someone enters the room (locks it). This process mirrors how monitor locks work in threads.

This rule governs the behavior of volatile variables in Java. When a thread writes to a volatile variable, the write is guaranteed to be visible to any thread that subsequently reads from the same variable. The use of volatile is essential in concurrent programming to ensure visibility without locking.

Think of a post-it note (volatile variable) that updates a message. When one person writes a new message on the note (write), anyone who looks at that note later (read) will see the updated message immediately. This is similar to how volatile variables ensure that updates are seen across threads.

This rule ensures that the order in which statements are executed within a single thread is preserved. If you write code in a sequence, that code will execute in that same sequence, which is crucial for maintaining logical flow and correct data handling.

Imagine following a recipe in the kitchen where you must combine ingredients in a specific order for a dish to turn out correctly. Just as you need to mix flour before adding eggs for a cake, operations within a thread must be executed in the order they are coded for expected results.

--