...
Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression in general includes both value computations and initiation of side effects. Value computation for an lvalue expression includes determining the identity of the designated object.
In a nutshell, all this keyword does is inform The volatile keyword informs the compiler that this the qualified variable may change in ways that cannot be determined; consequently, the compiler should not perform optimizations in optimizations must be restricted for memory areas marked as volatile. For example, the compiler should not store is forbidden to load the value in into a register and use the register instead of accessing expensive subsequently reuse the loaded value rather than accessing memory directly. This concept is closely related relates to multithreading because if incorrect caching of a shared variable is cached, a thread may change it, and the other threads may consequently read may interfere with the propagation of modified values between threads, causing some threads to view stale data.
This property of the The volatile keyword is sometimes misunderstood to provide atomicity of a variable that is for variables that are shared between threads in a multithreaded program. A variable Because the compiler is forbidden to either cache variables declared as volatile is not cached in a register, leading to the misunderstanding that it can be used safely as a synchronization primitive. When a variable is declared volatile, the compiler does not reorder in registers or to reorder the sequence of reads and writes to any given volatile variable, many programmers mistakenly believe that volatile variables can correctly serve as synchronization primitives. Although the compiler is forbidden to reorder the sequence of reads and writes to that memory location. However, the compiler might a particular volatile variable, it may legally reorder these reads and writes with those respect to reads and writes to other memory locations. Reordering might result in nonatomic operations on the synchronization variable, causing errors. Do not assume that the volatile qualifier provides any of This reordering alone is sufficient to make volatile variables unsuitable for use as synchronization primitives.
Further, the volatile qualifier lacks any guarantees regarding the following desired properties necessary for a multithreaded program:
- Atomicity: Indivisible memory operations.
- Visibility: The effects of a write action by a thread are visible to other threads.
- Ordering: Sequences of memory operations by a thread are guaranteed to be seen in the same order by other threads.
The volatile qualifier provides no lacks guarantees for any of these properties, either both by definition or and by the way it is implemented in various platforms. For more information on how volatile is implemented, consult DCL17-C. Beware of miscompiled volatile-qualified variables.
...
This noncompliant code example uses attempts to use flag as a synchronization primitive:
...
Declaring flag as volatile solves the problem of values being cached, which causes stale data to be read. However, volatile flag still does not fails to provide the atomicity and visibility guarantees needed for synchronization primitives to work correctly. The volatile keyword does not promise to provide the guarantees needed for synchronization primitives.
...