• 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

What's the point of having a copy of variable in thread

 
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is a bit embarrassing to ask... Feel like I should know this by now....

When talking about volatile variables, we always say that thread has a local copy of a variable from the main memory. Writes needs to be flushed out to take affect. I just realized this didn't make sense to me quite 100%. I think because I don't have enough knowledge on the hardware side.

What is the significance of that local copy of an variable? Does it correspond to register? CPU cache?
 
Marshal
Posts: 79153
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am not quite sure, but I think it corresponds to the copy in RAM. Rather than using the copy in a register or a cache, a volatile field must be written back to the object it belongs to, in the heap. So all changes are seen in the copy on the heap.
Anybody else know better than me?
 
Saloon Keeper
Posts: 15491
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah, threads are allowed to keep copies of a variable "somewhere". This is intentionally vague, so platforms are free to optimize code as they see fit. In practice, "somewhere" may refer to both the CPU registers and the CPU caches.

If two different threads perform operations on the same variable, they may actually perform operations on their cached copy of the variable, and when they finally write the result back to memory, they will overwrite the value another thread wrote to memory earlier. A volatile variable may not be cached, so when a thread performs an operation on it, another thread will immediately see the results of that operation. This does not guarantee however, that operations are performed in the proper order. For this you need to synchronize access to the variable.

Note that Java requires all platforms to update the variable in main memory when a thread leaves a critical section (synchronized block). This means that the volatile keyword is almost never used, because synchronizing your variable access is sufficient. Volatile variables are usually only used when they serve to signal one thread from another, and no other synchronization between them is needed:
Here the run() method is continuously running, performing some action until another thread signals the object to stop. A volatile boolean can be used instead of two synchronized methods, because the two threads perform atomic operations on it (a simple assign, and a simple access).
 
reply
    Bookmark Topic Watch Topic
  • New Topic