Skip to main content

Threads in Java - Volatile keyword (Part 9)

Volatile

If we mark a variable as "volatile", it means it will be read from the computer's main memory instead of CPU cache and every write will be to the computer's main memory only and not only in CPU cache.

When multiple threads operate on non-volatile variables, each thread may copy variables from the main memory to CPU cache for performance reasons. Let us say I have a computer with more than one CPU, each thread may run on a different CPU and hence deal with different CPU caches.
source: Jenkov

With non-volatile variables, there is no guarantee that the data in each CPU cache is the latest (updated) one. Hence, different threads may see different values of the same variable which can cause severe errors.

On the other hand, if we declare the shared variable as volatile then it will always be read from the main memory.

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.

Full volatile visibility guarantee

The full visibility guarantee is as follows
  • If Thread A writes to a volatile variable and Thread B subsequently reads the same variable, then all variables visible to Thread A will also be visible to Thread B before writing the volatile variable even after Thread B has read it already.
  • If Thread A reads a volatile variable, then all variables visible to Thread A when reading the volatile variable will also be re-read from the main memory.
public class Calendar {
    private int year;
    private int month
    private volatile int day;


    private void update(int year, int month, int day){
        this.years  = years;
        this.months = months;
        this.days   = days;
    }
}

In the above code, only day is volatile and when a value is written to days, the values of years and months are also written to the main memory.

Happens before guarantee

The JVM and CPU can reorder the instructions in a program provided the semantic meaning remains same. They do this for performance reasons.
For e.g.

int a = 1;
int b = 2;

a++;
b++;

These instructions can be reordered as -

int a = 1;
a++;

int b = 2;
b++;

Here the semantic meaning is not changed. But this reordering sometimes present some challenges as shown in below code -

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;
    }
}

When the value is written to days, the new values for months and years will also be written to the main memory. But what if JVM reorders the instructions like this -

public void update(int years, int months, int days){
    this.days   = days;
    this.months = months;
    this.years  = years;
}

This time the values for months and years are written to main memory before the new values for these variables are written. The new values are thus not properly made visible to other threads.

To solve this problem, volatile keyword gives "happens-before" guarantee. This means -

  • If the reads/writes originally occurred before the write to the volatile variable, the reads/writes to other variables cannot be reordered after a write to a volatile variable.
  • If reads/writes originally occurred after the reads of the volatile variable, reads/writes to other variables cannot be reordered to occur before read of a volatile variable.
If two threads are both reading and writing to a shared variable, only volatile is not enough. We should use synchronized block around the critical section. Or we can use many atomic datatypes in java.util.concurrent package such as AtomicInteger or AtomicLong.

Performance considerations

Since the use of volatile involves operation in the main memory instead of CPU cache, it is expensive. This also prevents reordering which is a normal performance technique. Thus, we should use volatile only when we absolutely need to enforce visibility of variables.

Conclusion

Congratulations!! 🙋 today we discussed the concepts of volatile variable and its applications. I hope you enjoyed this post.

I would love to hear your thoughts on this and would like have suggestions from you to make it better. 

Feel free to befriend me on FacebookTwitter or Linked In or say Hi by email.

Comments

Popular posts from this blog

Threads in Java - Masterclass (Part 0)

Multithreading is a way to introduce concurrency in a program. In any case, if there are parallel paths in our program (parts which do not depend on the result from another part), we can make use of multithreading.
One should exploit this feature, especially with all these multiple core machines nowadays.

Below are a few reasons why we should use multithreading -
1. Keep a process responsive There was once a time when you would print a document in MS Word and the application would freeze for an annoyingly long amount of time until the job finished. Eventually, Microsoft solved this problem by running a printing job parallel to the main thread/ GUI thread.  To be clear though, not only GUI apps but Network services have to keep an ear to the ground for new clients, dropped connections and cancellation requests. In either case, it is critical to do the heavy lifting on a secondary thread to keep the user satisfied. 2. Keep a processor busy Keeping a processor busy can be a tough task e…

Parsing XML using Retrofit

Developing our own type-safe HTTP library to interface with a REST API can be a real pain as we have to handle many aspects -
making connectionscachingretrying failed requeststhreadingresponse parsingerror handling, and more.  Retrofit, on the other hand, is a well-planned, documented and tested library that will save you a lot of precious time and headaches. In this tutorial, we are going to discuss how we can parse the XML response returned from https://timesofindia.indiatimes.com/rssfeedstopstories.cms using the Retrofit library.

To work with Retrofit, we need three classes -  Model class to map the JSON dataInterfaces which defines the possible HTTP operationsRetrofit.Builder class - Instance which uses the interface and the Builder API which allows defining the URL endpoint for the HTTP operation. Every method of the above interface represents on possible API call. The request type is specified by using appropriate annotations (GET, POST). The response is returned as a Call object…

Material design profile page in Android

Hey everyone, some days back I was working on one my personal Android project. In that project, I was supposed to create a simple profile page for a user. This profile page was supposed to show some basic details of a user.

The output of this UI will be like this -
I created the profile page using material design and in this post, I am going to discuss a step by step tutorial to create a simple yet elegant profile page. Without further ado, let's get started.
Creating a new project Click on File ➤ New Project ➤ Empty Activity and fill the necessary details. Change styles.xml fileNavigate to app\src\main\res\values\styles.xmlChange the style value from DarkActionBar to NoActionBar as below<resources><!-- Base application theme. --><stylename="AppTheme"parent="Theme.AppCompat.Light.NoActionBar"><!-- Customize your theme here. --><itemname="colorPrimary">@color/colorPrimary</item><itemname="colorPrimaryDark&qu…