• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Volatile Variable

 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When a thread writes a value to a volatile variable, does it synchronize all the latest values of its member variables to the main memory ?
 
Bartender
Posts: 1561
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This doesn't make much sense to me. I believe volatile means that the compiler will assume that the variable can be changed at any time. This prevents the compiler from maximally optimizing manipulations of this variable, but for good reason: safety. As far as I know, this has no effect on synchronization.

What do you mean though by all of .... member variables...?
 
Bartender
Posts: 4179
22
IntelliJ IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Santhosh Jali:
When a thread writes a value to a volatile variable, does it synchronize all the latest values of its member variables to the main memory ?



Yes. The assign action to a volatile variable must be immediately followed by a store action, which sends the new value to the main memory, and the combination of these two actions is considered atomic. Similarly, a use action on a volatile variable must be immediately preceded by a load action to get the value from main memory, and this combination of load-use is also atomic. What this basically means is that the volatile variable is used 'directly' from the main memory pool and not from the Thread memory pool, so you don't have to worry about synchronization barriers.
 
Steve Luke
Bartender
Posts: 4179
22
IntelliJ IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by pete stein:
What do you mean though by all of .... member variables...?



Good catch...

Santosh, do you mean the volatile variable is an Object, and you are wondering if the members of the Object are synchronized as well?

The answer to that is no. The variable only holds the reference to the object, and it is the reference that would be treated atomically for the assign-write operations. There would be no special relationship between the volatile nature of the reference variable and the Object whose reference it holds.
 
Kalyan Anand
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
ok.. here is what I read and confused. can someone explain what this means ?

The visibility effects of volatile variables extend beyond the value of the volatile variable itself. When thread A writes to a volatile variable and subsequently thread B reads that same variable, the values of all variables that were visible to A prior to writing to the volatile variable become visible to B after reading the volatile variable. So from a memory visibility perspective, writing a volatile variable is like exiting a synchronized block and reading a volatile variable is like entering a synchronized block. However, we do not recommend relying too heavily on volatile variables for visibility; code that relies on volatile variables for visibility of arbitrary state is more fragile and harder to understand than code that uses locking.
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

ok.. here is what I read and confused. can someone explain what this means ?



Wow, you really waded through the specification, huh?

The paragraph is referring to something that was added a few years ago. I think it was sometime around Java 5. It is basically saying that reading and writing volatile variables also affect the caching of other variables.

There are some really complex reasons why this is needed (which I am not completely sure of), but in a nutshell... the combination of using volatile variables and some of the "code motion" optimations broke stuff. So, this behavior was added to the JVM (and to the specification).

Henry
 
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can learn more about the problems with the original Java memory model, and the changes that were made for JDK 5, at Bill Pugh's Java Memory Model page. For your question on volatile, a good place to start might be What does volatile do?.

[Santhosh]: When a thread writes a value to a volatile variable, does it synchronize all the latest values of its member variables to the main memory ?

It's misleading to say "synchronize" here, since in Java, "synchronize" has a specific meaning. Volatile has some of the effects of synchronization, but not all of them. Volatile is like synchronization in terms of its effect on the memory model, but it's unlike synchronization in the sense that volatile will never block threads from concurrently accessing a particular method or block of code. Your question is apparently about the former effect only.

In answer to your question, I would say that the JVM will write and read to and from main memory, as necessary, in order to ensure that any data that was visible to thread A before it wrote to a volatile variable, will also be visible to thread B after it reads from the same volatile variable.

It's up to the JVM whether this means it writes/reads all data from a given object to/from main memory, or just some of it. Or none of it. It's possible that the JVM may determine that only one other field is being read after a volatile access, and therefore it's possible to refresh just that one field, leaving the other fields alone. It's hard for us to say. Basically, you can assume that your program will behave as if all the fields have been refreshed. If the JVM finds it's able to avoid some of that work without changing the behavior of the program (other than to make it faster), it may do so. It's often hard for us to know exactly what's really going on inside the JVM, because there are many optimizations that it performs.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic