0

I'm learning about volatile and synchronized in Java and I see that synchronized is used for read-modify-write operations like x++, and volatile is for read-write operations. And I want to ask you 2 questions. How looks a read-write operation?

And for the second question I have this code:

public class StopThread {
    private static volatile boolean stop;

    public static void main(String[] args) throws InterruptedException { 

        new Thread(new Runnable() {

            @Override
            public void run() {
                while (!stop) {
                    System.out.println("In while...");
                }
            }

        }).start();

        TimeUnit.SECONDS.sleep(1); 
        stop = true;
    }

}

And I don't understand why this is a read-write operation because the stop variable will be modified from false to true. So isn't this a read-modify-write operation? Thank you!

  • 1
    What's the difference between "modify" and "write"? – Andy Turner Mar 18 '19 at 18:27
  • https://stackoverflow.com/questions/3519664/difference-between-volatile-and-synchronized-in-java – Jamie Mar 18 '19 at 18:31
  • In this case, both the threads will be using the shared variable to do entirely different operations. Since a shared variable will be used, you need to synchronise it. One thread will be reading the variable, and the other will be modifying it. Call it whatever you want. – Prashant Pandey Mar 18 '19 at 19:09
  • IMO you are asking the wrong question. The problem with sharing data between threads is that in order to meaningfully update some data object, it often is necessary for one thread to temporarily put the object into some invalid or wrong state. By _correct_ use of `synchronized`, you can prevent other threads from ever seeing that invalid/wrong state. The `volatile` keyword is no help at all with that problem, but there is a secondary problem that both `volatile` and `synchronized` can help with... – Solomon Slow Mar 18 '19 at 20:01
  • ...The compiler, the run-time, and the hardware all are allowed to "optimize" your code. Those optimizations can assume that no data are shared between threads, and things can come out wrong if your threads actually _do_ share. The `volatile` keyword simply declares that "this variable is shared." The `synchronized` keyword does something more sophisticated: It guarantees that when thread A leaves a `synchronized(a)...` block, and then thread B subsequently enters `synchronized(a)...` (NOTE! same `a`), then thread B will be guaranteed to see everything that thread A did. – Solomon Slow Mar 18 '19 at 20:07
  • @AndyTurner in the phrase “read-modify-write”, “modify” means calculating the intended new value based on the read value whereas “write” means actually writing the calculated value back to the shared memory. – Holger Apr 02 '19 at 09:06

1 Answers1

4

The statement stop = true; is not a “read-write” operation but only a write. It doesn’t read the variable’s old value at all. If stop’s previous value was true, the statement had no effect, without noticing the difference.

A “read-modify-write” operation, also known as “read-update-write” operation implies an operation that reads the previous value, calculates a new value based on it, and writes the new value back to the variable. The problem with this operation, when not using a special atomic update construct, is that by the time, the write is performed, a concurrent update may have happened, so the variable is overwritten with a calculated value which is based on an outdated previous value.

For your boolean variable, “read-modify-write” operations may look like

if(!stop) stop = true;

or

stop = !stop;

but for the first variant, missing a concurrent update would not have much impact, as the statement has no effect if the variable is already true. The second may miss updates if performed concurrently, hence, not reflect the correct number of flip operations, but using concurrent boolean updates for more than a single state transition is error prone in general.

A “read-write” operation, i.e without a “modify/update” in between, would be an operation that reads the old value for later use and writes a new value not based on the old value. Like

Type old = variable;
variable = newValue;
// use old here

which still would be subject to lost updates when not done atomically. Thus, such operation also needs more than a volative variable. E.g. AtomicInteger.getAndSet or VarHandle.getAndSet.

So expanding your example to

import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.LockSupport;

public class StopThread {
    private static volatile boolean stop;

    public static void main(String[] args) throws InterruptedException { 

        new Thread(new Runnable() {
            @Override
            public void run() {
                while(!stop) {
                    System.out.println("In while...");
                }
            }
        }).start();
        for(int i = 0; i < 5; i++) {
            new Thread(new Runnable() {
                @Override
                public void run() {
                    LockSupport.parkNanos(TimeUnit.SECONDS.toNanos(1)); 
                    boolean old = stop; // broken because
                    stop = true;        // not atomic
                    System.out.println(old? "other thread was faster": "sent stop signal");
                }
            }).start();
        }
    }
}

multiple threads may think that they sent the stop signal.

If you fix the code to

import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicBoolean;
import java.util.concurrent.locks.LockSupport;

public class StopThread {
    private static final AtomicBoolean stop = new AtomicBoolean();

    public static void main(String[] args) throws InterruptedException { 

        new Thread(new Runnable() {
            @Override
            public void run() {
                while(!stop.get()) {
                    System.out.println("In while...");
                }
            }
        }).start();
        for(int i = 0; i < 5; i++) {
            new Thread(new Runnable() {
                @Override
                public void run() {
                    LockSupport.parkNanos(TimeUnit.SECONDS.toNanos(1)); 
                    boolean old = stop.getAndSet(true);
                    System.out.println(old? "other thread was faster": "sent stop signal");
                }
            }).start();
        }
    }
}

exactly one thread will take the responsibility of having sent the stop signal.

Holger
  • 285,553
  • 42
  • 434
  • 765