Threads: All About Volatile

I was thinking to improve my threading fundamentals, so I planned to make few notes for myself that will assist me in future (Obviously at the time of Interviews). Following questions and answers have been taken from stackoverflow.com. This post is a sticky notes post for me. Please do not use the answers for reference purpose.

Here we will try to concentrate on basic questions on volatile. Volatile has been quite a common word in threading world, but it has not been utilized so much in codes. Let’s start digging little deeper to figure out about volatile.

Do you ever use the volatile keyword in Java?

When exactly do you use the volatile keyword in Java?

Most of the information has been taken from https://www.ibm.com/developerworks/java/library/j-jtp06197/. I have tried to get the extract of the article.

Volatile variables can perform subset of things that synchronize block can perform. In general cases, lock offers mutual exclusion and visibility feature. Mutual exclusion facilitated only one thread to access the shared resources, whereas visibility means that inconsistent data must not be visible across different threads. Volatile variables can only provide visibility feature to the application.

If a variable is declared volatile, so any thread reading the variable will always see the most updated value of the variable.

Java 5 onward, to access a volatile variable JVM creates a memory barrier and synchronize the main memory will all cached instances, and returns latest and most updated information.

Volatile variables must be used where their assignment do not depend on previous value.

volVar += 1; //It is not a correct use to volatile variables.

That’s why volatile variables cannot be used as counters.

Volatile variables are preferred over Synchronized blocks due to Simplicity, No need to write lot of code, and scalability, no locks are held while processing, but volatile has got its own restrictions as well.

Conditions for correct use of volatile

You can use volatile variables instead of locks only under a restricted set of circumstances. Both of the following criteria must be met for volatile variables to provide the desired thread-safety:

• Writes to the variable do not depend on its current value.
• The variable does not participate in invariant with other variables.

Patterns for using volatile correctly

Though people discourage to use to volatile variables, but still there are few well defined patterns to use volatile variables.

Pattern #1: status flags

In Producer/consumer problem we change the status of the flag so that other thread can enter in the critical section and can read or write the data. The access of the block is managed with a Boolean. This Boolean can be volatile variables.

volatile boolean stopRequested;
public void stop() { stopRequested = true; }
public void doWork() { 
    while (!stopRequested) { 
        // do stuff
    }
}

Now if you will see the transactions performed on volatile variables, then you will realize that volatile variable’s state was not considered while updating it. So this is the correct use of volatile variable.

Pattern #2: one-time safe publication

Without synchronization, sometime it is possible to see updated object’s reference but stale data. It is quite a tricky problem, but it can be handled with volatile variable.

A key requirement for this pattern is that the object being published must either be thread-safe or effectively immutable (effectively immutable means that its state is never modified after its publication). The volatile reference may guarantee the visibility of the object in its as-published form, but if the state of the object is going to change after publication, then additional synchronization is required.

public class BackgroundFloobleLoader {
    public volatile Flooble theFlooble;

    public void initInBackground() {
        // do lots of stuff
        theFlooble = new Flooble();  // this is the only write to theFlooble
    }
}

public class SomeOtherClass {
    public void doWork() {
        while (true) { 
            // do some stuff...
            // use the Flooble, but only if it is ready
            if (floobleLoader.theFlooble != null) 
                doSomething(floobleLoader.theFlooble);
        }
    }
}

Pattern #3: independent observations

It is very similar to temperature reading. Temperature is read and written in the memory which can be accessed by multiple threads.

There are few more patterns listed in the article, but those patterns will need further understanding of java related technologies.

Threads: Why is it not good practice to synchronize on Boolean?

I was thinking to improve my threading fundamentals, so I planned to make few notes for myself that will assist me in future (Obviously at the time of Interviews). Following questions and answers have been taken from stackoverflow.com. This post is a sticky notes post for me. Please do not use the answers for reference purpose.

Here I got information to post for my reference.

Why is it not good practice to synchronize on Boolean?

Instead writing something new, I am taking the same example that is also copied from other blog post.

private Boolean isOn = false;
private String statusMessage = "I'm off";
public void doSomeStuffAndToggleTheThing(){
   // Do some stuff
   synchronized(isOn){
      if(isOn){
         isOn = false;
         statusMessage = "I'm off";
         // Do everything else to turn the thing off
      } else {
         isOn = true;
         statusMessage = "I'm on";
         // Do everything else to turn the thing on
      }
   }
}

As it turned out that it is not possible to get a neat lock on Booleans. As due to auto boxing mechanism (As you can get lock on objects only), true and false are Auto boxed to Boolean.True and Boolean.False objects. In a JVM, there can be only one object for Boolean.True and another object for Boolean.False. So application is written in a way that multiple threads locks on Boolean at various places, then it is possible that the complete code will be messed up without our knowledge, and it will be difficult to figure out the reason without knowing about Boolean classes.

Taken from the answer 2by McDowell

This is a terrible idea. isOn will reference the same object as Boolean.FALSE which is publicly available. If any other piece of badly written code also decides to lock on this object, two completely unrelated transactions will have to wait on each other. Locks are performed on object instances, not on the variables that reference them:

Any Boolean that is created through autoboxing (isOn = true) is the same object as Boolean.TRUE which is a singleton in theClassLoader across all objects. Your lock object should be local to the class it is used in. The proper pattern if you need to lock around a boolean is to define a private final lock object:

Let’s assume that our application does not have any other thread which is locking on Boolean object, then also above mentioned code is vulnerable and it is a good candidate for RACE Condition.

Let’s say one thread enters in the synchronized block when isOn was false. In this case Thread.False object is locked, and thread is in critical section of the code. Now isOn is changed to true, and after this another thread try to grab a lock on the same section. Thread.True is not locked with any other thread, which means that Thread 2 will grab the lock and will enter into critical section.

In this scenario mentioned above, both the threads are accessing critical section simultaneously which is not a desired scenario for us.

Following issue can be fixed with the following ways

There are loads of ways you could fix this:

• Synchronize on this
• Synchronize on a private final Object specifically designated for the purpose (neater if someone else might extend our class)
• Replace isOn with a final AtomicBoolean that you can alter using get and set methods rather than assignments (you’ll still need to synchronize for testing the state)
• Redesign the class to avoid this sort of faffing about (such as using constant message Strings for each state)

This is a fairly subtle consequence of the Java abstraction, and could have caused me a huge headache if it had gone unchecked – leaving one of those wonderfully annoying intermittent bugs floating around (the kind that take forever to track down and debug).

BOTTOM LINE: Avoid using primitives types which might change in critical section, and be aware of Autoboxing.

Threads: Avoid synchronized(this) in Java

I was thinking to improve my threading fundamentals, so I planned to make few notes for myself that will assist me in future (Obviously at the time of Interviews). Following questions and answers have been taken from stackoverflow.com. This post is a sticky notes post for me. Please do not use the answers for reference purpose.

This is a quite an interesting question, and questioner has followed every answer quite religiously. Though question seems like naïve, questioner has taken the discussion to different planet altogether.

Avoid synchronized(this) in Java?

Whenever a question pops up on SO about Java synchronization, some people are very eager to point out that synchronized(this) should be avoided. Instead, they claim, a lock on a private reference is to be preferred.

Some of the given reasons are:

• some evil code may steal your lock (very popular this one, also has an "accidentally" variant)

Try to avoid synchronizing on this because that would allow everybody from the outside who had a reference to that object to block my synchronization. Instead, I create a local synchronization object:

public class Foo {

    private final Object syncObject = new Object();

    …

}

Now I can use that object for synchronization without fear of anybody “stealing” the lock.

• all synchronized methods within the same class use the exact same lock, which reduces throughput

The issue is that a synchronized method is actually just syntax sugar for getting the lock on this and holding it for the duration of the method. Thus, public synchronized void setInstanceVar() would be equivalent to something like this:

public void setInstanceVar() {

    synchronized(this) {

        instanceVar++;

    }

}

This is bad for two reasons:

• All synchronized methods within the same class use the exact same lock, which reduces throughput
• Anyone can get access to the lock, including members of other classes.

• you are (unnecessarily) exposing too much information

The equivalent of that is:

synchronized (this)

{

}

(And no, you shouldn't generally do it in either C# or Java. Prefer locking on private references which nothing else has access to. You may be aware of that already, of course - but I didn't want to leave an answer without the warning :)

People argue that synchronized(this) is an idiom that is used a lot (also in Java libraries), is safe and well understood. It should not be avoided because you have a bug and you don't have a clue of what is going on in your multithreaded program. In other words: if it is applicable, then use it.

Answer

1. Some evil code may steal your lock (very popular this one, also has an "accidentally" variant)

I'm more worried about accidentally. What it amounts to is that this use of this is part of your class' exposed interface, and should be documented. Sometimes the ability of other code to use your lock is desired. This is true of things like Collections.synchronizedMap (see the javadoc).

2. All synchronized methods within the same class use the exact same lock, which reduces throughput

This is overly simplistic thinking; just getting rid of synchronized(this) won't solve the problem. Proper synchronization for throughput will take more thought.

3. You are (unnecessarily) exposing too much information

This is a variant of #1. Use of synchronized(this) is part of your interface. If you don't want/need this exposed, don't do it.

But in the same thread one more person has proved that defensive approach is required in some of the cases while dealing with threads.

Let's say your system is a servlet container, and the object we're considering is the ServletContextimplementation. Its getAttribute method must be thread-safe, as context attributes are shared data; so you declare it as synchronized. Let's also imagine that you provide a public hosting service based on your container implementation.

I'm your customer and deploy my "good" servlet on your site. It happens that my code contains a call togetAttribute.

A hacker, disguised as another customer, deploys his malicious servlet on your site. It contains the following code in the init method:

synchronized (this.getServletConfig().getServletContext()) {

   while (true) {}

}

Assuming we share the same servlet context (allowed by the spec as long as the two servlets are on the same virtual host), my call on getAttribute is locked forever. The hacker has achieved a DoS on my servlet.

This attack is not possible if getAttribute is synchronized on a private lock, because 3rd-party code cannot acquire this lock.

I admit that the example is contrived and an over simplistic view of how a servlet container works, but IMHO it proves the point.

So I would make my design choice based on security consideration: will I have complete control over the code that has access to the instances? What would be the consequence of a thread's holding a lock on an instance indefinitely?

Discussion can be concluded saying that it is mandatory to define the purpose of threading and various other aspect of the application, and accordingly we must implements the Synchronization.

Threads: Difference between Synchronized Block and Synchronized Method

I was thinking to improve my threading fundamentals, so I planned to make few notes for myself that will assist me in future (Obviously at the time of Interviews). Following questions and answers have been taken from stackoverflow.com. This post is a sticky notes post for me.

What is the difference between a synchronized method and synchronized block in Java?

What is the difference between synchronized methods and blocks?

Let’s look at some code to know Synchronized method and Synchronized block.

Synchronized method

public synchronized void synchronizedMethod(){
//Do something in this method
}

Synchronized block

                public void synchronizedBlock(){

                                //Do Something before Synchronization

                                synchronized(this){

                                                //Do Something here in synchronized block.

                                }

                                //Do Something after Synchronization

                }

When static method is synchronized, then class’s object (created by Class.forName()) is locked whereas in  case of instance method, class’s instance (this) is locked.

When a block is synchronized, then developer has to choose the object to lock. JVM implicitly do not lock anything here.

Something that JSR says

JLS 14.19 The synchronized Statement

A synchronized statement acquires a mutual-exclusion lock on behalf of the executing thread, executes a block, and then releases the lock. While the executing thread owns the lock, no other thread may acquire the lock.

JLS 8.4.3.6 synchronized Methods

A synchronized method acquires a monitor before it executes. For a class (static) method, the monitor associated with the Class object for the method's class is used. For an instance method, the monitor associated with this (the object for which the method was invoked) is used.

These are the same locks that can be used by the synchronized statement; thus, the code:

class Test {

    int count;

    synchronized void bump() { count++; }

    static int classCount;

    static synchronized void classBump() {

        classCount++;

    }

}

Has exactly the same effect as:

class BumpTest {

    int count;

    void bump() {

        synchronized (this) {

            count++;

        }

    }

    static int classCount;

    static void classBump() {

        try {

            synchronized (Class.forName("BumpTest")) {

                classCount++;

            }

        } catch (ClassNotFoundException e) {

                ...

        }

    }

}

Difference between block and method

Lock scope

For synchronized methods, the lock will be held throughout the method scope, whereas in the synchronized blocks, the lock is held only during the synchronized block (otherwise known as critical section).

Objects

In synchronized method, implicit monitor (this) is obtained, whereas in case of blocks developer has to decide the object to lock.

Let’s look at some JVM generated machine code and IBM’s advice

When the JVM executes a synchronized method, the executing thread identifies that the method's method_info structure has the ACC_SYNCHRONIZED flag set, then it automatically acquires the object's lock, calls the method, and releases the lock. If an exception occurs, the thread automatically releases the lock.

Synchronizing a method block, on the other hand, bypasses the JVM's built-in support for acquiring an object's lock and exception handling and requires that the functionality be explicitly written in byte code. If you read the byte code for a method with a synchronized block, you will see more than a dozen additional operations to manage this functionality. Listing 1 shows calls to generate both a synchronized method and a synchronized block.

package com.geekcap; public class SynchronizationExample {     private int i;     public synchronized int synchronizedMethodGet() {         return i;     }     public int synchronizedBlockGet() {         synchronized( this ) {             return i;         }     } }

The synchronizedMethodGet() method generates the following byte code:

0:            aload_0                 1:            getfield                 2:            nop                 3:            iconst_m1                 4:            ireturn

And here's the byte code from the synchronizedBlockGet() method:

0:            aload_0                 1:            dup                 2:            astore_1                 3:            monitorenter                 4:            aload_0                 5:            getfield                 6:            nop                 7:            iconst_m1                 8:            aload_1                 9:            monitorexit                 10:          ireturn                 11:          astore_2                 12:          aload_1                 13:          monitorexit                 14:          aload_2                 15:          athrow

Creating the synchronized block yielded 16 lines of bytecode, whereas synchronizing the method returned just 5.

So here is piece of advice whenever you think of using synchronized block, think of minimizing the synchronized code, if you want to synchronize the complete code within the method, then do not push your mind hard and let JVM optimize the code for you.

A quote from Effective Java 2nd Edition, Item 67: Avoid excessive synchronization:

As a rule, you should do as little work as possible inside synchronized regions.

Threads: Why must wait() always be in synchronized block?

I was thinking to improve my threading fundamentals, so I planned to make few notes for myself that will assist me in future (Obviously at the time of Interviews). Following questions and answers have been taken from stackoverflow.com. This post is a sticky notes post for me.

Source

This question is more specific to design aspect of java. Why should object.wait() method be called from a synchronized block? Why is this necessary to acquire monitor of the object? Why cannot application ask a Running thread to wait for sometimes? (Very similar to sleep)

As per the accepted answer, wait and notify are used for inter thread communication. When a thread is waiting for nothing, then what specific condition should wake this thread? On what grounds JVM sends a notification to the thread?

In another answer, an explanation is provided with an example.

package com.thread.problem;

public class Information {

                private String message;

                private boolean isAvailToWrite = false;

                public boolean isAvailable(){

                                return isAvailToWrite;

                }

                public boolean isUnavailable(){

                                return !isAvailToWrite;

                }

                public void put(String msg) throws InterruptedException{

                               while(isUnavailable()){

                                                                System.out.println("Producer will wait now.");

                                                                wait();

                                                }

                                                message = msg;

                                                isAvailToWrite = true;

                                                notify();

                }

                public String get() throws InterruptedException{

                                while(isAvailable()){

                                                                System.out.println("Consumer will wait now.");

                                                                wait();

                                                }

                                                isAvailToWrite = false;

                                                notify();

                                                return message;

                }

}

There are 2 threads i.e. producer and consumer. Producer is calling put method to generate the Information, whereas consumer is digesting this specific information.

Now let’s assume things happen in following sequence.

1. Consumer thread invokes, and makes a call to get method. It checks that nothing is available, and consumer thread enters in the while block.
2.  JVM starts producer thread here.
3. Producer thread puts the information and invoke notify.
4. As consumer has not reached to the wait state, so it does not care about it.
5. Now consumer has started waiting.
6. Producer is never invoked after that.

So in this case main will keep running and no output will be generated.

Adding synchronized blocks to the above solution. No thread will be in intermittent state, and producer and consumer will work as expected.

package com.thread.problem;

public class Information {

                private String message;

                private boolean isAvailToWrite = false;

                public boolean isAvailable(){

                                return isAvailToWrite;

                }

                public boolean isUnavailable(){

                                return !isAvailToWrite;

                }

                public void put(String msg) throws InterruptedException{

                                synchronized (this) {

                                                while(isUnavailable()){

                                                                System.out.println("Producer will wait now.");

                                                                wait();

                                                }

                                                message = msg;

                                                isAvailToWrite = true;

                                                notify();

                                }

                }

                public String get() throws InterruptedException{

                                synchronized (this) {

                                                while(isAvailable()){

                                                                System.out.println("Consumer will wait now.");

                                                                wait();

                                                }

                                                isAvailToWrite = false;

                                                notify();

                                                return message;

                                }

                }

}

Now let’s follow the sequence specified above.

1. Consumer thread invokes, and makes a call to get method. It checks that nothing is available, and consumer thread enters in the while block. It can only exit until it completes its operations. So it will reach to wait state.
2. JVM starts producer thread here.
3. Producer thread puts the information and invoke notify.
4. As consumer is in wait state, so it will awake at notify call.
5. Consumer will consume the information and notify the producer to generate more information.

Here is one good explanation for the need of wait in a synchronized block.

 wait() isn't strictly guaranteed to do anything at all. Something called "spurious wakeups" might occur. That is, a call to wait() can
return at any time without any good reason. So a good rule of thumb for using wait() is that you should consider it to be nothing but an optimization. If a program issn't correct already (and assuming that thread starvation is not occurring), calling wait() can NOT make a program correct. However, it certainly can make a program incorrect!

So we need to start out thinking of how we'd write the code without wait at all. So how do you wait for something is wait() doesn't do anything? Easy... you do a busy-wait:

while (!thingImWaitingFor()) /* DO NOTHING */;

This uses 100% of the CPU power available, of course, and performance horribly. The optimization is this:
while (!thingImWaitingFor()) wait();

That explains the need for a "condition", which in this case is !thingImWaitingFor(). Next, you need a guarantee that the
waiter and the notifier agree about the state of the condition. The waiter checks the state of the predicate at some point slightly BEFORE it goes to sleep, but it depends for correctness on the condition being true WHEN it goes to sleep. There's a period of vulnerability between those two events, which can break the program. (Vulnerability has been explained above with the producer and consumer example)

You need that period of vulnerability to be protected by a synchronized block. If the waiter didn't synchronize, then any old bit of code might change the predicate just before it goes to sleep, and then we're certainly in trouble. If the notifier didn't synchronize, then it could change the predicate even though the waiter is holding the lock, and we are screwed.

However, the waiter can't hold a synchronized lock while it's waiting. At first glance, this problem seems impossible. Now, there's actually a bit of magic involved here. The wait() method ATOMICALLY releases the lock and goes to sleep. It's a sort of deus ex machina solution (deus == Java Virtual Machine) to the otherwise impossible problem.