• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 160
  • Last Modified:

what is volatile and atomic in java

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
0
Rohit Bajaj
Asked:
Rohit Bajaj
  • 3
  • 2
  • 2
  • +1
2 Solutions
 
krakatoaCommented:
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.
0
 
dpearsonCommented:
When to declare a variable volatile or atomic?
Volatile and Atomic are both very similar in what they do.  In general, these days you should prefer Atomic like this:

private AtomicBoolean _verificationInProgress = new AtomicBoolean(false) ;

Atomics are newer additions to the language and offer more operations than volatile variables do (e.g. atomic gets and sets).

Now the question is - when do you need either volatile or atomic?

The answer to that is when the variable is shared between multiple threads.  If you are going to be updating or reading this variable from more than 1 thread, then you should make it atomic.

Doug
0
 
Rohit BajajAuthor 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 ?
0
Cloud Class® Course: Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.

 
dpearsonCommented:
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
0
 
krakatoaCommented:
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.
0
 
Rohit BajajAuthor 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 ?
0
 
CPColinSenior Java ArchitectCommented:
Not infinite, just longer than you meant it to go.
0
 
dpearsonCommented:
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
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

  • 3
  • 2
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now