23.3.1. Without Synchronization

class VisibilityDemo {
    static boolean flag = false;
    public static void main(String[] args) {
        new Thread(() -> {
            while (!flag) {
                // spin
            }
            System.out.println("Flag is true");
        }).start();
        try { Thread.sleep(1000); } catch (InterruptedException e) {}
        flag = true;
    }
}

This code snippet defines a class named VisibilityDemo. Within this class, a static boolean variable named flag is initialized to false. The main method creates a new thread that enters a loop, checking the state of flag. The loop continues running as long as flag is false, effectively causing the thread to 'spin' until it detects that flag has become true. After a pause of one second, the main method sets flag to true, which ideally should allow the new thread to exit the loop and print 'Flag is true'.

Think of the thread like a security guard waiting for a signal before stopping a patrol. The guard keeps checking whether the alarm (the flag) has been set off. Meanwhile, the 'main' office (the main method) waits a bit and then eventually sets off the alarm (sets flag to true). If the guard can't see the alarm change, he continues his patrol indefinitely, which reflects the problem with visibility without proper synchronization.

Problem: The thread may never see flag = true because the compiler or CPU might optimize the loop.

The crucial problem here is related to visibility between threads. When one thread modifies a variable, like setting flag to true, it should be visible to other threads. However, due to compiler or CPU optimizations, changes made to flag might not be seen immediately by the other thread. This could lead the new thread to believe that flag remains false, causing it to spin infinitely. This scenario illustrates a common concurrency issue called 'visibility problems', which arise when the memory state is not synchronized effectively between threads.

Imagine two people trying to coordinate a delivery. One person (the 'main' thread) calls the delivery service to change a delivery time but can't physically tell the other person (the thread) directly. Instead, they write it down on a piece of paper. If the delivery service only updates their records once in a while (like CPU optimizations), the second person might keep thinking the delivery time is unchanged, leading to confusion. Proper communication (synchronization) is essential so both parties are always on the same page.

--