volatile

Uploaded by

nyzir.barry

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PPTX, PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

5 views8 pages

volatile

Uploaded by

nyzir.barry

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PPTX, PDF, TXT or read online on Scribd

You are on page 1/ 8

Keyword: Volatile

 The Java volatile keyword is used to mark a Java variable as "being stored in main
memory". More precisely that means, that every read of a volatile variable will be
read from the computer's main memory, and not from the CPU cache, and that
every write to a volatile variable will be written to main memory, and not just to
the CPU cache.

 Actually, since Java 5 the volatile keyword guarantees more than just that volatile
variables are written to and read from main memory
In a multithreaded application where the threads operate on non-volatile variables, each thread may copy
variables from main memory into a CPU cache while working on them, for performance reasons. If your
computer contains more than one CPU, each thread may run on a different CPU. That means, that each thread
may copy the variables into the CPU cache of different CPUs. This is illustrated here:

With non-volatile variables there are no guarantees about when the Java Virtual Machine (JVM) reads
data from main memory into CPU caches, or writes data from CPU caches to main memory. This can
cause several problems
public class SaharedObject
{
public int counter=0;
}
If the counter variable is not declared volatile there is no guarantee about when the value of the counter variable
is written from the CPU cache back to main memory
. This means, that the countervariable value in the CPU cache may not be the same as in main memory. This
situation is illustrated here:
The problem with threads not seeing the latest value of a variable because it has not yet been written
back to main memory by another thread, is called a "visibility" problem. The updates of one thread
are not visible to other threads.
So java solves this with volatile keyword.

 The Java volatile Visibility Guarantee

The Java volatile keyword is intended to address variable visibility problems.
By declaring the countervariable volatile all writes to the counter variable will be written back to main
memory immediately.
Also, all reads of the counter variable will be read directly from main memory.

public class SharedObject

{
public volatile int counter = 0;
}
Full volatile Visibility Guarantee
Actually, the visibility guarantee of Java volatile goes beyond the volatile variable itself.
The visibility guarantee is as follows:
•If Thread A writes to a volatile variable and Thread B subsequently reads the same
volatile variable, then all variables visible to Thread A before writing the volatile variable,
will also be visible to Thread B after it has read the volatile variable.
•If Thread A reads a volatile variable, then all all variables visible to Thread A when
reading the volatile variable will also be re-read from main memory.

public class MyClass {

private int years;
private int months;
private volatile int days;
public void update(int years, int months, int days){
this.years = years;
this.months = months;
this.days = days;
}
}
Volatile is Not Always Enough
• Even if the volatile keyword guarantees that all reads of
a volatile variable are read directly from main memory, and all writes
to a volatile variable are written directly to main memory, there are
still situations where it is not enough to declare a variable volatile.
• As soon as a thread needs to first read the value of a volatile variable,
and based on that value generate a new value for the
shared volatile variable, a volatile variable is no longer enough to
guarantee correct visibility. The short time gap in between the reading
of the volatile variable and the writing of its new value, creates
an race condition where multiple threads might read the same value
of the volatile variable, generate a new value for the variable, and
when writing the value back to main memory - overwrite each other's
values.
• The situation where multiple threads are incrementing the same
counter is exactly such a situation where a volatile variable is not
enough. The following sections explain this case in more detail.
When is volatile Enough?

• if two threads are both reading and writing to a shared variable, then using the volatile keyword for that is not
enough. You need to use a synchronized in that case to guarantee that the reading and writing of the variable is
atomic. Reading or writing a volatile variable does not block threads reading or writing. For this to happen you
must use the synchronized keyword around critical sections.
• In case only one thread reads and writes the value of a volatile variable and other threads only read the variable,
then the reading threads are guaranteed to see the latest value written to the volatile variable. Without making the
variable volatile, this would not be guaranteed.
• As an alternative to a synchronized block you could also use one of the many atomic data types found in
the java.util.concurrent package. For instance, the AtomicLong or one of the others.

Performance Considerations of volatile

 Reading and writing of volatile variables causes the variable to be read or written to main memory. Reading from
and writing to main memory is more expensive than accessing the CPU cache. Accessing volatile variables also
prevent instruction reordering which is a normal performance enhancement technique. Thus, you should only use
volatile variables when you really need to enforce visibility of variables.
Thank you
Source of this data: http://tutorials.jenkov.com/java-concurrency/volatile.html