Let&#39;s say that a class has a `public int counter` field that is accessed by multiple threads. This `int` is only incremented or decremented.

To increment this field, which approach should be used, and why?


 * `lock(this.locker) this.counter++;`,
 * `Interlocked.Increment(ref this.counter);`,
 * Change the access modifier of `counter` to `public volatile`.

Now that I&#39;ve discovered `volatile`, I&#39;ve been removing many `lock` statements and the use of `Interlocked`. But is there a reason not to do this?

Volatile vs. Interlocked vs. lock

At work today, I came across the `volatile` keyword in Java. Not being very familiar with it, I found [this explanation](http://web.archive.org/web/20210221170926/https://www.ibm.com/developerworks/java/library/j-jtp06197/). 

Given the detail in which that article explains the keyword in question, do you ever use it or could you ever see a case in which you could use this keyword in the correct manner?

What is the volatile keyword useful for?

Why is `volatile` needed in C? What is it used for? What will it do?

Why is volatile needed in C?

&gt; **Possible Duplicate:**  
&gt; https://stackoverflow.com/questions/72552/

&lt;!-- End of automatically inserted text --&gt;

I have never used it but I wonder why people use it? What does it exactly do? I searched the forum, I found it only C# or Java topics.

Why do we use volatile keyword?

How do atomic / volatile / synchronized work internally?

What is the difference between the following code blocks?

Code 1

    private int counter;
    
    public int getNextUniqueIndex() {
        return counter++; 
    }

Code 2

    private AtomicInteger counter;
    
    public int getNextUniqueIndex() {
        return counter.getAndIncrement();
    }

Code 3

    private volatile int counter;
    
    public int getNextUniqueIndex() {
        return counter++; 
    }

---

Does `volatile` work in the following way? Is

    volatile int i = 0;
    void incIBy5() {
        i += 5;
    }

equivalent to 

    Integer i = 5;
    void incIBy5() {
        int temp;
        synchronized(i) { temp = i }
        synchronized(i) { i = temp + 5 }
    }


I think that two threads cannot enter a synchronized block at the same time... am I right? If this is true then how does `atomic.incrementAndGet()` work without `synchronized`? And is it thread-safe?

And what is the difference between internal reading and writing to volatile variables / atomic variables? I read in some article that the thread has a local copy of the variables - what is that?

What is the difference between atomic / volatile / synchronized?

What does AtomicBoolean do that a volatile boolean cannot achieve?

Volatile boolean vs AtomicBoolean

I am wondering at the difference between declaring a variable as `volatile` and always accessing the variable in a `synchronized(this)` block in Java?

According to this article http://www.javamex.com/tutorials/synchronization_volatile.shtml there is a lot to be said and there are many differences but also some similarities.

I am particularly interested in this piece of info:

&gt; ...
&gt;
- access to a volatile variable never has the potential to block: we&#39;re only ever doing a simple read or write, so unlike a synchronized block we will never hold on to any lock;
- because accessing a volatile variable never holds a lock, it is not suitable for cases where we want to **read-update-write** as an atomic operation (unless we&#39;re prepared to &quot;miss an update&quot;);

What do they mean by **read-update-write**? Isn&#39;t a write also an update or do they simply mean that the **update** is a write that depends on the read?

Most of all, when is it more suitable to declare variables `volatile` rather than access them through a `synchronized` block? Is it a good idea to use `volatile` for variables that depend on input? For instance, there is a variable called `render` that is read through the rendering loop and set by a keypress event?

Difference between volatile and synchronized in Java

Is it correct to say that `static` means one copy of the value for all objects and `volatile` means one copy of the value for all threads? 

Anyway a `static` variable value is also going to be one value for all threads, then why should we go for `volatile`?

Volatile vs Static in Java

What does the `volatile` keyword do? In C++ what problem does it solve?

In my case, I have never knowingly needed it.

Why does volatile exist?

As demonstrated in [this answer](https://stackoverflow.com/questions/2478397/atomic-swap-in-gnu-c/2478520#2478520) I recently posted, I seem to be confused about the utility (or lack thereof) of `volatile` in multi-threaded programming contexts.

My understanding is this: any time a variable may be changed outside the flow of control of a piece of code accessing it, that variable should be declared to be `volatile`.  Signal handlers, I/O registers, and variables modified by another thread all constitute such situations.

So, if you have a global int `foo`, and `foo` is read by one thread and set atomically by another thread (probably using an appropriate machine instruction), the reading thread sees this situation in the same way it sees a variable tweaked by a signal handler or modified by an external hardware condition and thus `foo` should be declared `volatile` (or, for multithreaded situations, accessed with memory-fenced load, which is probably a better a solution).

How and where am I wrong?

Why is volatile not considered useful in multithreaded C or C++ programming?

If there are two threads accessing a global variable then many tutorials say make the variable volatile to prevent the compiler caching the variable in a register and it thus not getting updated correctly.
However two threads both accessing a shared variable is something which calls for protection via a mutex isn&#39;t it? 
But in that case, between the thread locking and releasing the mutex the code is in a critical section where only that one thread can access the variable, in which case the variable doesn&#39;t need to be volatile?

So therefore what is the use/purpose of volatile in a multi-threaded program?

When to use volatile with multi threading?

I read somewhere below line.

&gt; Java volatile keyword doesn&#39;t means atomic, its common misconception
&gt; that after declaring volatile, `++` operation will be atomic, to make
&gt; the operation atomic you still need to ensure exclusive access using
&gt; `synchronized` method or block in Java.

So what will happen if two threads attack a `volatile` primitive variable at same time? 

Does this mean that whosoever takes lock on it, that will be setting its value first. And if in meantime, some other thread comes up and read old value while first thread was changing its value, then doesn&#39;t new thread will read its old value?

What is the difference between Atomic and volatile keyword?

Volatile Vs Atomic

I read some articles about the `volatile` keyword but I could not figure out its correct usage.  Could you please tell me what it should be used for in C# and in Java?

What is the &quot;volatile&quot; keyword used for?

After reading [The JSR-133 Cookbook for Compiler Writers][1] about the implementation of volatile, especially section &quot;Interactions with Atomic Instructions&quot; I assume that reading a volatile variable without updating it needs a LoadLoad or a LoadStore barrier. Further down the page I see that LoadLoad and LoadStore are effectively no-ops on X86 CPUs. Does this mean that volatile read operations can be done without a explicit cache invalidation on x86, and is as fast as a normal variable read (disregarding the reordering constraints of volatile)? 

I believe I don&#39;t understand this correctly. Could someone care to enlighten me? 

EDIT: I wonder if there are differences in multi-processor environments. On single CPU systems the CPU might look at it&#39;s own thread caches, as John V. states, but on multi CPU systems there must be some config option to the CPUs that this is not enough and main memory has to be hit, making volatile slower on multi cpu systems, right?

PS: On my way to learn more about this I stumbled about the following great articles, and since this question may be interesting to others, I&#39;ll share my links here:

* [Java theory and practice: Fixing the Java Memory Model, Part 1][2] and
* [Java theory and practice: Fixing the Java Memory Model, Part 2][3] 


  [1]: http://gee.cs.oswego.edu/dl/jmm/cookbook.html
  [2]: http://www.ibm.com/developerworks/library/j-jtp02244.html
  [3]: http://www.ibm.com/developerworks/library/j-jtp03304/

Is volatile expensive?

I have a question about the difference between volatile and mutable. I noticed that both of the two means that it could be changed. What else? Are they the same thing? What&#39;s the difference? Where are they applicable? Why the two ideas are proposed? How to use them in different way?

Thanks a lot. 

volatile vs. mutable in C++

I have read &quot;[When to use &#39;volatile&#39; in Java?][1]&quot; but I&#39;m still confused. How do I know when I should mark a variable volatile? What if I get it wrong, either omitting a volatile on something that needs it or putting volatile on something that doesn&#39;t? What are the rules of thumb when figuring out what variables should be volatile in multithreaded code?


  [1]: http://www.javamex.com/tutorials/synchronization_volatile_when.shtml

When exactly do you use the volatile keyword in Java?

I would like to code a little program which visually illustrates the behavior of the `volatile` keyword. Ideally, it should be a program which performs concurrent access to a non volatile static field and which gets incorrect behavior because of that. 

Adding the volatile keyword in the same program should fix the problem.

That something I didn&#39;t manage to achieve. Even trying several times, enabling optimization, etc., I always get a correct behavior without the &#39;volatile&#39; keyword.

Do you have any idea about this topic? Do you know how to simulate such a problem in a simple demo app? Does it depend on hardware?

Illustrating usage of the volatile keyword in C#

Multiple texts say that when implementing double-checked locking in .NET the field you are locking on should have volatile modifier applied. But why exactly? Considering the following example:

    public sealed class Singleton
    {
       private static volatile Singleton instance;
       private static object syncRoot = new Object();
    
       private Singleton() {}
    
       public static Singleton Instance
       {
          get 
          {
             if (instance == null) 
             {
                lock (syncRoot) 
                {
                   if (instance == null) 
                      instance = new Singleton();
                }
             }
    
             return instance;
          }
       }
    }

why doesn&#39;t &quot;lock (syncRoot)&quot; accomplish the necessary memory consistency? Isn&#39;t it true that after &quot;lock&quot; statement both read and write would be volatile and so the necessary consistency would be accomplished?

The need for volatile modifier in double checked locking in .NET

I understand that `volatile` informs the compiler that the value may be changed, but in order to accomplish this functionality, does the compiler need to introduce a memory fence to make it work?

From my understanding, the sequence of operations on volatile objects cannot be reordered and must be preserved. This seems to imply some memory fences are necessary and that there isn&#39;t really a way around this. Am I correct in saying this?

----

There is an interesting discussion at [this related question][1]

[Jonathan Wakely writes][2]:

&gt; ... Accesses to distinct volatile variables cannot be reordered by the
&gt; compiler as long as they occur in separate full expressions ... right
&gt; that volatile is useless for thread-safety, but not for the reasons he
&gt; gives. It&#39;s not because the compiler might reorder accesses to
&gt; volatile objects, but because the CPU might reorder them. Atomic
&gt; operations and memory barriers prevent the compiler and the CPU from
&gt; reordering

To which [David Schwartz][3] replies [in the comments][4]:

&gt; ... There&#39;s no difference, from the point of view of the C++ standard,
&gt; between the compiler doing something and the compiler emitting
&gt; instructions that cause the hardware to do something. If the CPU may
&gt; reorder accesses to volatiles, then the standard doesn&#39;t require that
&gt; their order be preserved. ...
&gt; 
&gt; ... The C++ standard doesn&#39;t make any distinction about what does the
&gt; reordering. And you can&#39;t argue that the CPU can reorder them with no
&gt; observable effect so that&#39;s okay -- the C++ standard defines their
&gt; order as observable. A compiler is compliant with the C++ standard on
&gt; a platform if it generates code that makes the platform do what the
&gt; standard requires. If the standard requires accesses to volatiles not
&gt; be reordered, then a platform the reorders them isn&#39;t compliant. ...
&gt; 
&gt; My point is that if the C++ standard prohibits the compiler from
&gt; reordering accesses to distinct volatiles, on the theory that the
&gt; order of such accesses is part of the program&#39;s observable behavior,
&gt; then it also requires the compiler to emit code that prohibits the CPU
&gt; from doing so. The standard does not differentiate between what the
&gt; compiler does and what the compiler&#39;s generate code makes the CPU do.

Which does yield two questions: Is either of them &quot;right&quot;? What do actual implementations really do?

  [1]: https://stackoverflow.com/questions/14785639/may-accesses-to-volatiles-be-reordered
  [2]: https://stackoverflow.com/a/14789387/321013
  [3]: https://stackoverflow.com/users/721269/david-schwartz
  [4]: https://stackoverflow.com/questions/14785639/may-accesses-to-volatiles-be-reordered?lq=1#comment20732711_14789387

Does the C++ volatile keyword introduce a memory fence?

`volatile` is to tell the compiler not to optimize the reference, so that every read/write does not use the value stored in register but does a real memory access. I can understand it is useful for some ordinary variable, but don&#39;t understand how `volatile` affects a pointer.

    volatile int *p = some_addr;
    int a = *p; // CPU always has to load the address, then does a memory access anyway, right?

What is the difference if it has been declared as `int *p = some_addr`?

Why is a point-to-volatile pointer, like &quot;volatile int * p&quot;, useful?

I&#39;m reading about *volatile* keyword in Java and completely understand the theory part of it.

But, what I&#39;m searching for is, a good case example, which shows what would happen if variable wasn&#39;t *volatile* and if it were.

Below code snippet doesn&#39;t work as expected (taken from [here][1]):

    class Test extends Thread {
    
        boolean keepRunning = true;
    
        public void run() {
            while (keepRunning) {
            }
    
            System.out.println(&quot;Thread terminated.&quot;);
        }
    
        public static void main(String[] args) throws InterruptedException {
            Test t = new Test();
            t.start();
            Thread.sleep(1000);
            t.keepRunning = false;
            System.out.println(&quot;keepRunning set to false.&quot;);
        }
    }

Ideally, if `keepRunning` wasn&#39;t *volatile*, thread should keep on running indefinitely. But, it does stop after few seconds.

I&#39;ve got two basic questions:

 - Can anyone explain volatile with example? Not with theory from JLS.
 - Is volatile substitute for synchronization? Does it achieve atomicity?


  [1]: https://stackoverflow.com/a/10764147/2546848

Simplest and understandable example of volatile keyword in Java

Is the compiler allowed to optimize this (according to the C++17 standard):

    int fn() {
        volatile int x = 0;
        return x;
    }

to this?

    int fn() {
        return 0;
    }

If yes, why? If not, why not?

--------------------

Here&#39;s some thinking about this subject: current compilers compile `fn()` as a local variable put on the stack, then return it. For example, on x86-64, gcc creates this:

    mov    DWORD PTR [rsp-0x4],0x0 // this is x
    mov    eax,DWORD PTR [rsp-0x4] // eax is the return register
    ret    

Now, as far as I know the standard doesn&#39;t say that a local volatile variable should be put on the stack. So, this version would be equally good:

    mov    edx,0x0 // this is x
    mov    eax,edx // eax is the return
    ret    

Here, `edx` stores `x`. But now, why stop here? As `edx` and `eax` are both zero, we could just say:

    xor    eax,eax // eax is the return, and x as well
    ret    

And we transformed `fn()` to the optimized version. Is this transformation valid? If not, which step is invalid?

Is it allowed for a compiler to optimize away a local volatile variable?

Is it sufficient to declare an instance of a structure-typed variable as volatile (if its fields are accessed in re-entrant code), or must one declare specific fields of the structure as volatile?

Phrased differently, what are the semantic differences (if any) between:

    typdef struct {
      uint8_t bar;
    } foo_t;
    
    volatile foo_t foo_inst;

and 

    typedef struct{
      volatile uint8_t bar;
    } foo_t;
    
    foo_t foo_inst;

I recognize that declaring a pointer-typed variable as volatile (e.g. volatile uint8_t * foo) merely informs the compiler that the address pointed-to by foo may change, while making no statement about the values pointed to by foo. It is unclear to me whether an analogy holds for structure-typed variables.



Volatile Struct Semantics

From what I&#39;ve read from [Herb Sutter][1] and [others][2] you would think that `volatile` and concurrent programming were completely orthogonal concepts, at least as far as C/C++ are concerned.

However, in GCC [implementation][3] all of `std::atomic`&#39;s member functions have the `volatile` qualifier.  The same is true in Anthony Williams&#39;s [implementation][4] of `std::atomic`.

So what&#39;s deal, do my `atomic&lt;&gt;` variables need be `volatile` or not?

  [1]: http://herbsutter.wordpress.com/2009/01/12/effective-concurrency-volatile-vs-volatile/
  [2]: http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/
  [3]: https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/files.html
  [4]: http://www.stdthread.co.uk/doc/headers/atomic/atomic.html

Why is the volatile qualifier used through out std::atomic?

According to:

http://www.ibm.com/developerworks/library/j-jtp03304/
&gt;Under the new memory model, when thread A writes to a volatile variable V, and thread B reads from V, any variable values that were visible to A at the time that V was written are guaranteed now to be visible to B

And many places on the internet state that the following code should never print &quot;error&quot;:

    public class Test {
        volatile static private int a;
        static private int b;
	
        public static void main(String [] args) throws Exception {
        	for (int i = 0; i &lt; 100; i++) {
        		new Thread() {
        			
        			@Override
        			public void run() {
        				int tt = b; // makes the jvm cache the value of b
        				
        				while (a==0) {
						
        				}
        				
        				if (b == 0) {
        					System.out.println(&quot;error&quot;);
        				}
        			}
				
        		}.start();
        	}
		
        	b = 1;
        	a = 1;
        }
    }

`b` **should** be 1 for all the threads when `a` is 1.

However **I sometimes get &quot;error&quot; printed**. How is this possible?

Why doesn&#39;t volatile in java 5+ ensure visibility from another thread?

Some languages provide a `volatile` modifier that is described as performing a &quot;read memory barrier&quot; prior to reading the memory that backs a variable.

A read memory barrier is commonly described as a way to ensure that the CPU has performed the reads requested before the barrier before it performs a read requested after the barrier. However, using this definition, it would seem that a stale value could still be read. In other words, performing reads in a certain order does not seem to mean that the main memory or other CPUs must be consulted to ensure that subsequent values read actually reflect the latest in the system at the time of the read barrier or written subsequently after the read barrier.

So, does volatile really guarantee that an up-to-date value is read or just (gasp!) that the values that are read are at least as up-to-date as the reads before the barrier? Or some other interpretation? What are the practical implications of this answer?


How do I Understand Read Memory Barriers and Volatile

Is a volatile `int` in Java thread-safe? That is, can it be safely read from and written to without locking?

Is a volatile int in Java thread-safe?

I&#39;m having a theoretical (non-deterministic, hard to test, never happened in practice) hardware issue reported by hardware vendor where double-word write to certain memory ranges may corrupt any future bus transfers.

While I don&#39;t have any double-word writes explicitly in C code, I&#39;m worried the compiler is allowed (in current or future implementations) to coalesce multiple adjacent word assignments into a single double-word assignment.

The compiler is not allowed to reorder assignments of volatiles, but it is unclear (to me) whether coalescing counts as reordering. My gut says it is, but I&#39;ve been corrected by language lawyers before!

Example:

```
typedef struct
{
   volatile unsigned reg0;
   volatile unsigned reg1;
} Module;

volatile Module* module = (volatile Module*)0xFF000000u;

// two word stores, or one double-word store?
module-&gt;reg0 = 1;
module-&gt;reg1 = 2;
```

(I&#39;ll ask my compiler vendor about this separately, but I&#39;m curious what the canonical/community interpretation of the standard is.)

Is a C compiler allowed to coalesce sequential assignments to volatile variables?

While reading I came across this type of declaration and the following line  -

    const volatile char *p=(const volatile char *) 0x30;

&gt;The value of p is changed by external conditions only


I don&#39;t get what are the external conditions . And also what is practical use of this type of _declaration_?

Pointer declared as constant as well as volatile

What basically `__asm__ __volatile__ ()` does and what is significance of `&quot;memory&quot;` for ARM architecture?


Working of __asm__ __volatile__ (&quot;&quot; : : : &quot;memory&quot;)

I&#39;ve looked at the other volatile vs. Atomicxxxx questions in SO (including [this one][1]) and have read [the description of java.util.current.atomic][2], and I am not quite satisfied with the nuances.

If I&#39;m trying to decide between using `volatile boolean` and `AtomicBoolean`, are there practical differences besides the atomic read-modify-write operations offered by AtomicBoolean? (e.g. `compareAndSet()` and `getAndSet()`)

Suppose I have

    volatile boolean flag;

Then one or more threads set the flag (but not clear it). If I have one thread that reads the flag, and if set, does an action, and then clears the flag, is `volatile` adequate?

Is there a higher cost to AtomicBoolean than volatile boolean, in terms of

 - memory space
 - performance hit (`volatile boolean` appears to require memory fencing, `AtomicBoolean` appears to require memory fencing + some minor locking on CAS operations as per the java.util.current.atomic description)

My gut call is to just go with AtomicBoolean and be safe, but I want to understand if there&#39;s ever a situation to use `volatile boolean` instead (e.g. if I had thousands of instances of them and performance were an issue).

  [1]: https://stackoverflow.com/questions/3786825/java-volatile-boolean-vs-atomicboolean
  [2]: http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/atomic/package-summary.html

When is it preferable to use volatile boolean in Java rather than AtomicBoolean?

I occasionally use a `volatile` instance variable in cases where I have two threads reading from / writing to it and don&#39;t want the overhead (or potential deadlock risk) of taking out a lock; for example a timer thread periodically updating an int ID that is exposed as a getter on some class:

    public class MyClass {
      private volatile int id;
    
      public MyClass() {
        ScheduledExecutorService execService = Executors.newScheduledThreadPool(1);
        execService.scheduleAtFixedRate(new Runnable() {
          public void run() {
            ++id;
          }
        }, 0L, 30L, TimeUnit.SECONDS);
      }
    
      public int getId() {
        return id;
      }
    }

My question: Given that the JLS only guarantees that 32-bit reads will be atomic is there any point in **ever** using a volatile long? (i.e. 64-bit).

**Caveat**: Please do not reply saying that using `volatile` over `synchronized` is a case of pre-optimisation; I am well aware of how / when to use `synchronized` but there are cases where `volatile` is preferable.  For example, when defining a Spring bean for use in a single-threaded application I tend to favour `volatile` instance variables, as there is no guarantee that the Spring context will initialise each bean&#39;s properties in the main thread.

Is there any point in using a volatile long?

I am still pretty new to the concept of threading, and try to understand more about it. Recently, I came across a blog post on [What Volatile Means in Java][1] by Jeremy Manson, where he writes: 

&gt; When one thread writes to a volatile variable, and another thread sees
&gt; that write, the first thread is telling the second about **all** of the
&gt; contents of memory up until it performed the write to that volatile
&gt; variable. [...] **all** of the memory contents seen by Thread 1, before
&gt; it wrote to `[volatile] ready`, must be visible to Thread 2, after it
&gt; reads the value `true` for `ready`. [emphasis added by myself]

Now, does that mean that all variables (volatile or not) held in Thread 1&#39;s memory at the time of the write to the volatile variable will become visible to Thread 2 after it reads that volatile variable? If so, ***is it possible to puzzle that statement together from the official Java documentation/Oracle sources? And from which version of Java onwards will this work?***

In particular, if all Threads share the following class variables:

    private String s = &quot;running&quot;;
    private volatile boolean b = false;

And Thread 1 executes the following first:

    s = &quot;done&quot;;
    b = true;

And Thread 2 then executes afterwards (after Thread 1 wrote to the volatile field):

    boolean flag = b; //read from volatile
    System.out.println(s);

Would this be guaranteed to print &quot;done&quot;?

***What would happen if instead of declaring `b` as `volatile` I put the write and read into a `synchronized` block?***

Additionally, in a discussion entitled &quot;[Are static variables shared between threads?][2]&quot;, @TREE [writes][3]:

&gt; Don&#39;t use volatile to protect more than one piece of shared state.

***Why?*** (Sorry; I can&#39;t comment yet on other questions, or I would have asked there...)

  [1]: http://jeremymanson.blogspot.co.uk/2008/11/what-volatile-means-in-java.html
  [2]: https://stackoverflow.com/questions/4934913/are-static-variables-shared-between-threads
  [3]: https://stackoverflow.com/questions/4934913/are-static-variables-shared-between-threads#comment5502155_4934966


Happens-before relationships with volatile fields and synchronized blocks in Java - and their impact on non-volatile variables?

I saw some examples in java where they do synchronization on a block of code to change some variable while that variable was declared volatile originally .. I saw that in an example of singleton class where they declared the unique instance as volatile and they sychronized the block that initializes that instance ... My question is why we declare it volatile while we synch on it, why we need to do both?? isn&#39;t one of them is sufficient for the other ??

    public class SomeClass {
        volatile static Object uniqueInstance = null;

        public static Object getInstance() {
            if (uniqueInstance == null) {
                synchronized (someClass.class) {
                    if (uniqueInstance == null) {
                        uniqueInstance = new SomeClass();
                    }
                }
            }
            return uniqueInstance;
        }
    }
thanks in advance.




All Volatile Solutions on Gang of Coders

Total of 34 Volatile Solutions