We help IT Professionals succeed at work.

what is volatile and atomic in java

Rohit Bajaj
Rohit Bajaj asked
on
209 Views
Last Modified: 2015-01-03
Hi,
I want to know the meaning of atomic and volatile variables in java. When to declare a variable volatile or atomic?

I have the following variable in my code -
    private boolean _verificationInProgress = false;
should i make it atomic or voltaile and why ?

This variable is inside a class whose instance is only created once during the lifecycle of an application and used elsewhere.
Thanks
Comment
Watch Question

CERTIFIED EXPERT

Commented:
Have you read the lit on this? The API doc is actually quite good at explaining the similarities and wider functions of the atomic kit. Look here.
CERTIFIED EXPERT
Commented:
This one is on us!
(Get your first solution completely free - no credit card required)
UNLOCK SOLUTION

Author

Commented:
Hi,
I read the following example for volatile -
volatile boolean stop = false;
void loop() {
    while (!stop) { ... }
}
void stop() { stop = true; }
If you have a thread running loop() and another thread calling stop(), you might run into an infinite loop if you omit "volatile", since the first thread might cache the value of stop

Here i dont understand how will the thread get into infinite loop. As after the value of stop gets updated why will it not get reflected to the other thread. I think it may not be immediate but still it will be less than a fraction of second even if we dont declare the variable as volatile.
Also how does a thread in java caches variables ?
CERTIFIED EXPERT

Commented:
As after the value of stop gets updated why will it not get reflected to the other thread?

This is actually a pretty subtle feature in the way threads work.  The problem is that there can be 2 CPUs, each running a different thread.  If you don't tell the compiler that the "stop" variable needs to be shared between the threads, then each thread is allowed to keep the "stop" variable in its local processor cache as long as it wishes (which could be for minutes for a tight loop).

It does NOT need to send that value back to the main memory.

So since the value is stored in the local processor cache, the 2nd thread cannot see it (since each processor has its own cache).  This sort of bug literally will not happen if you run it on a machine with a single CPU.  It can only show up on a machine with multiple CPUs (or at least multiple cores).

If you use "synchronize" or "volatile" or "AtomcBoolean" - all of them tell the compiler "this variable is shared between threads" and now when its value changes that value WILL ALWAYS be sent back to main memory - making it visible to all other threads.

Does that make sense?

It's pretty complicated.

Doug
CERTIFIED EXPERT

Commented:
I don't know (but do care) what Doug might have on this take, but my "sketch" would be that 'volatile' is more akin to a superstatic variable if you see what I mean - IOW one that is practically shared amongst threads, but protected at the same time. With 'volatile' you can prescribe protected treatment of primitives, which otherwise is more convoluted to achieve.

java.util.concurrent.atomic and friends is more angled to the access and implementation of protection, so it's more of a way of validating access and ensuring consistency, rather than personal variable bodyguarding, if that makes any sense. So volatile - var wears a body vest. Atomic, entourage shoots the assassin.

Author

Commented:
HI,
Even if there is a single CPU. Each thread can keep its local copy and use it. I think this way also there can be possibility of infinite loop ?
CPColinSenior Java Architect
Commented:
This one is on us!
(Get your first solution completely free - no credit card required)
UNLOCK SOLUTION
CERTIFIED EXPERT

Commented:
Even if there is a single CPU. Each thread can keep its local copy and use it.

If there's a single CPU, then when we context switch between the threads,  the local cache will be cleared (at least that's my understanding of how the processor cache works - it could be wrong and/or processor architecture specific).  If the cache is cleared, then the next time the cache is loaded (from main memory), the other thread will see the correct value.

So on a single CPU machine the longest wait would be the time until the next context switch - which is maybe a few milliseconds if we have 2 threads ready to run.  If one of the threads is blocked, then I guess this could be an arbitrary wait.  But on a machine with 2 CPUs (or 16 CPUs), if there are only 2 threads, you could be waiting for a long time before that next context switch happens because each thread gets its own CPU and there's no need for a context switch.

The take home of all this is:

    To write correct multi-threaded code, any variable that is shared between 2 threads MUST use some sort of concurrent indicator (volatile, synchronized, Atomic...) for the code to work correctly in all situations.

Without this you violate the Java memory model and Java is allowed to produce fast, but incorrect code.

Doug
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.