Declaring a static variable in Java, means that there will be only one copy, no matter how many objects of the class are created. The variable will be accessible even with no Objects created at all. However, threads may have locally cached values of it. When a variable is volatile and not static, there will … Read more
Consider this code, int some_int = 100; while(some_int == 100) { //your code } When this program gets compiled, the compiler may optimize this code, if it finds that the program never ever makes any attempt to change the value of some_int, so it may be tempted to optimize the while loop by changing it … Read more
You basically use it when you want to let a member variable be accessed by multiple threads but do not need compound atomicity (not sure if this is the right terminology). class BadExample { private volatile int counter; public void hit(){ /* This operation is in fact two operations: * 1) int tmp = this.counter; … Read more
I use volatile fields when said field is ONLY UPDATED by its owner thread and the value is only read by other threads, you can think of it as a publish/subscribe scenario where there are many observers but only one publisher. However if those observers must perform some logic based on the value of the … Read more
You are specifically asking about how they internally work, so here you are: No synchronization private int counter; public int getNextUniqueIndex() { return counter++; } It basically reads value from memory, increments it and puts back to memory. This works in single thread but nowadays, in the era of multi-core, multi-CPU, multi-level caches it won’t … Read more
Worst (won’t actually work) Change the access modifier of counter to public volatile As other people have mentioned, this on its own isn’t actually safe at all. The point of volatile is that multiple threads running on multiple CPUs can and will cache data and re-order instructions. If it is not volatile, and CPU A … Read more
volatile tells the compiler not to optimize anything that has to do with the volatile variable. There are at least three common reasons to use it, all involving situations where the value of the variable can change without action from the visible code: When you interface with hardware that changes the value itself; when there’s … Read more
It’s important to understand that there are two aspects to thread safety. execution control, and memory visibility The first has to do with controlling when code executes (including the order in which instructions are executed) and whether it can execute concurrently, and the second to do with when the effects in memory of what has … Read more
The problem with volatile in a multithreaded context is that it doesn’t provide all the guarantees we need. It does have a few properties we need, but not all of them, so we can’t rely on volatile alone. However, the primitives we’d have to use for the remaining properties also provide the ones that volatile … Read more
In C++11, don’t use volatile for threading, only for MMIO But TL:DR, it does “work” sort of like atomic with mo_relaxed on hardware with coherent caches (i.e. everything); it is sufficient to stop compilers keeping vars in registers. atomic doesn’t need memory barriers to create atomicity or inter-thread visibility, only to make the current thread … Read more