Understanding Race Conditions and Critical Sections

1. The Problem: When Threads Collide

Imagine you have a single bank account with a balance of ₹10,000. You and a friend both have debit cards for this account and go to different ATMs at the exact same moment to withdraw ₹7,000. In a sequential world, one transaction would complete before the other starts. But in a concurrent world, what might happen?

• Thread 1 (You): Reads the balance (₹10,000). The check passes.
• Thread 2 (Friend): Reads the balance (₹10,000) before you can update it. The check passes.
• Thread 1 (You): Dispenses ₹7,000 and updates the balance to ₹3,000.
• Thread 2 (Friend): Dispenses ₹7,000 and updates the balance to ₹3,000.

The final balance is ₹3,000, but ₹14,000 has been withdrawn. The bank has lost money because both threads "raced" to act on old information. This scenario is called a race condition.

This flowchart illustrates the same problem. Both processes read the initial balance of 100. Process 2 performs a subtraction and updates the balance to 90. Then, Process 1, which is still working with the old value of 100, performs an addition and updates the balance to 110, overwriting the change made by Process 2. The final result is incorrect.

A race condition occurs when a program's correctness depends on the unpredictable sequence or timing of threads being scheduled by the operating system. The result becomes non-deterministic, meaning you might get a different, incorrect answer every time you run the code.

2. A Race Condition in Java Code

This isn't just a theoretical problem. It happens frequently in code. Let's consider a simple counter.

public class Counter {
    private int count = 0;

    public void increment() {
        count++;
    }

    public int getCount() {
        return count;
    }
}

If we create a single Counter object and share it between two threads, each calling increment() one million times, we'd expect the final count to be two million. Let's see what actually happens.

As you saw in the video, the final count is not two million, and it varies with each run. Why does this happen? The reason is that the seemingly simple operation count++ is not atomic. It's not one indivisible instruction. The JVM breaks it down into three distinct steps:

1. Read: Get the current value of count.
2. Modify: Add one to the value.
3. Write: Store the new value back into count.

Now, let's see how the thread scheduler can interleave these operations and cause an error.

When Thread A reads the count (e.g., 0), the scheduler might pause it and let Thread B run. Thread B also reads the count (still 0), increments it to 1, and writes 1 back. Then, Thread A resumes. It already read 0, so it increments that value to 1 and writes 1 back. Two increment operations were performed, but the count only increased by one. An update was lost.

3. The Critical Section

The specific part of the code that accesses a shared resource and can lead to a race condition is known as a critical section.

Formally, a critical section is a piece of code that must be executed by at most one thread at a time to ensure correctness. In our Counter example, the increment() method, and specifically the line count++, is the critical section.

Problems only arise when multiple threads attempt to write to a shared resource within a critical section. If multiple threads are only reading a shared, unchanging resource, there is no risk of a race condition.

A critical section is not always a single line of code. It can be a sequence of operations that must be treated as a single, atomic unit.

This example is crucial. The individual operations (donutsNumber.get() and donutsNumber.addAndGet()) might be atomic, but the logic if (check) { act } is not. The entire block—the check and the action—constitutes the critical section. If another thread can modify the state between the check and the action, a race condition occurs. This is a classic "check-then-act" race condition pattern.

4. A Preview of the Solution: Mutual Exclusion

So, how do we protect our critical sections and prevent race conditions? The solution is to enforce mutual exclusion, which means ensuring that only one thread can execute the code inside a critical section at any given time.

If Thread 1 enters a critical section, any other thread that tries to enter must be blocked and forced to wait until Thread 1 has finished and exited the critical section. This makes the entire block of code effectively atomic.

In Java, the most common way to achieve mutual exclusion is by using the synchronized keyword. By marking a method or a block of code as synchronized, you tell the JVM to acquire an intrinsic lock before executing it, thereby preventing other threads from entering at the same time.

We will dive deep into the mechanics of the synchronized keyword in our next lesson. For now, the key takeaway is that you must first identify your critical sections before you can protect them.

5. Coding Exercise: See the Race Condition for Yourself

Theory is one thing, but seeing is believing. Let's reproduce the race condition.

1. In your IDE, create the Counter class as defined earlier in this lesson.
2. Create a new Runnable task. In its constructor, accept a Counter object.
3. In the run() method of your Runnable, create a for loop that iterates 100,000 times, calling the counter.increment() method in each iteration.
4. In your main method:
   • Create a single instance of Counter.
   • Create two Thread objects. Pass a new instance of your Runnable task to each, making sure to give both of them the same Counter object.
   • Start both threads.
   • After starting them, you need to wait for them to finish. Use the join() method for this:

     // Assuming your thread objects are named t1 and t2
     try {
         t1.join();
         t2.join();
     } catch (InterruptedException e) {
         e.printStackTrace();
     }
     

     The join() method causes the main thread to pause until the thread it's called on has completed its execution.
   • After the join() calls, print the final value from counter.getCount().

Run your program multiple times. What do you observe? You should see that the final count is almost never the expected 200,000 and that the result changes with each run. You have now successfully created and witnessed a race condition.

Conclusion

In this lesson, we have moved from simply creating threads to understanding the fundamental dangers of concurrent modification. This is a critical step towards writing correct and robust multithreaded applications.

Key Takeaways:

• A race condition is an error that occurs when the correctness of a program depends on the unpredictable scheduling of multiple threads accessing shared resources.
• The primary cause is non-atomic operations, like the read-modify-write pattern (e.g., count++) or the check-then-act pattern.
• A critical section is the specific block of code that accesses a shared resource and must be protected to prevent race conditions.
• The conceptual solution is to enforce mutual exclusion, ensuring only one thread can be in a critical section at a time, making it an atomic operation.

Now that we have thoroughly diagnosed the problem, our next lesson will focus entirely on the cure. We will dive deep into Java's synchronized keyword to learn how to enforce mutual exclusion and make our critical sections thread-safe.