Why volatile is weaker form of synchronization?

Question

As mentioned from Java_author,

The Java language also provides an alternative, weaker form of synchronization, volatile variables, to ensure that updates to a variable are propagated predictably to other threads.

So, my understanding is,

the below code that uses locking(synchronized) to provide (mutual exclusion + memory visibility),

public class SynchronizedInteger{
    private int value;

    public synchronized int get(){ return value; }
    public synchronized void set(int value){ this.value = value; }
}

can also be written just using volatile keyword providing (mutual exclusion + memory visibility), shown below,

public class SynchronizedInteger{
    private volatile int value;

    public int get(){ return value; }
    public void set(int value){ this.value = value; }
}

But,

Why volatile usage is weaker form of synchronization?
Book says: writing a volatile variable is like exiting a synchronized block and reading a volatile variable is like entering a synchronized block

Can multiple threads writing to volatile memory area value, holds mutual exclusion?

Where did you get the idea that `volatile` provides mutual exclusion? — shmosel, Oct 08 '17 at 20:33
@shmosel My understanding that `volatile` provides mutual exclusion is because, book says, *writing a `volatile` variable is like exiting a `synchronized` block and reading a `volatile` variable is like entering a `synchronized` block*, which am still not clear, what it means. I have this in query — overexchange, Oct 08 '17 at 21:17
They have the same atomicity and visibility guarantees. There's no concept of mutual exclusion with `volatile`. — shmosel, Oct 08 '17 at 21:22
@shmosel But [JSR-133 author](http://jeremymanson.blogspot.ca/2007/08/atomicity-visibility-and-ordering.html) says, *Atomicity deals with which actions and sets of actions have indivisible effects. This is the aspect of concurrency most familiar to programmers: it is usually thought of in terms of mutual exclusion.* Aren't atomicity/mutual_exclusion mean same? — overexchange, Oct 08 '17 at 21:25
Not in this context. Mutual exclusion is one of several ways to achieve atomicity. — shmosel, Oct 08 '17 at 21:43

Adam Kotwasinski · Accepted Answer · 2017-10-08T20:23:01.797

1

volatile cannot create a critical section on other entities, while synchronized can.

e.g.

synchronized (something) {
    something.doSomething();
    somethingElse.doSomethingElse();
}

With volatile, you can "protect" only the entity made volatile.

Regarding

Can multiple threads writing to volatile memory area value, holds mutual exclusion?

No. Each read/write operation on that entity is atomic. Remember that operations like value++ are composed of read and write, and need to be taken care of separately.

edited Oct 08 '17 at 20:23

answered Oct 08 '17 at 20:13

Adam Kotwasinski

4,377
3
17
40

1

You mean compound actions can be dealt with `synchronized` unlike `volatile` or `AtomicLong`. – overexchange Oct 08 '17 at 20:18
So, *weaker* in terms of not handling more than what it can? as mentioned in my previous comment? – overexchange Oct 08 '17 at 20:30
@overexchange Yes, weaker as in very often you need to use a different mechanism (e.g. `synchronized`) to have your goals met. You cannot do multiple operations with `volatile`, only a simple read or a simple write are atomic. – Adam Kotwasinski Oct 08 '17 at 20:33
Which means that even an increment isn't atomic, since it's a read operation and a write operation. – David Schwartz Oct 10 '17 at 18:12

score 0 · Answer 2 · answered Oct 10 '17 at 18:09

volatile is variable access modifier which forces all threads to get latest value of the variable from main memory. No locking is required to access volatile variables.

synchronized is method level/block level access restriction modifier. It will make sure that one thread owns the lock for critical section. Only the thread,which own a lock can enter synchronized block. If other threads are trying to access this critical section, they have to wait till current owner releases the lock. You can have many statements in synchronized blocks/methods.

Why volatile usage is weaker form of synchronization?

If one thread modifies the value of variable and other threads read the value of that variable, adding volatile access modifier to a variable makes some sense. If multiple threads are modifying and reading value of variable, volatile access modifier does not guarantee data consistency. But if you synchronize update/read code blocks, data consistency is guaranteed.

Can multiple threads writing to volatile memory area value, holds mutual exclusion?

No. Since locking is not involved when you use volatile access modifier.

Why volatile is weaker form of synchronization?

2 Answers2