Volatile (computer programming)

Last updated

In computer programming, particularly in the C, C++, C#, and Java programming languages, the volatile keyword indicates that a value may change between different accesses, even if it does not appear to be modified. This keyword prevents an optimizing compiler from optimizing away subsequent reads or writes and thus incorrectly reusing a stale value or omitting writes. Volatile values primarily arise in hardware access (memory-mapped I/O), where reading from or writing to memory is used to communicate with peripheral devices, and in threading, where a different thread may have modified a value.

Contents

Despite being a common keyword, the behavior of volatile differs significantly between programming languages, and is easily misunderstood. In C and C++, it is a type qualifier, like const , and is a property of the type . Furthermore, in C and C++ it does not work in most threading scenarios, and that use is discouraged. In Java and C#, it is a property of a variable and indicates that the object to which the variable is bound may mutate, and is specifically intended for threading. In the D programming language, there is a separate keyword shared for the threading usage, but no volatile keyword exists.

In C and C++

In C, and consequently C++, the volatile keyword was intended to [1]

Operations on volatile variables are not atomic, nor do they establish a proper happens-before relationship for threading. This is specified in the relevant standards (C, C++, POSIX, WIN32), [1] and volatile variables are not threadsafe in the vast majority of current implementations. Thus, the usage of volatile keyword as a portable synchronization mechanism is discouraged by many C/C++ groups. [2] [3] [4]

Example of memory-mapped I/O in C

In this example, the code sets the value stored in foo to 0. It then starts to poll that value repeatedly until it changes to 255:

staticintfoo;voidbar(void){foo=0;while(foo!=255);}

An optimizing compiler will notice that no other code can possibly change the value stored in foo, and will assume that it will remain equal to 0 at all times. The compiler will therefore replace the function body with an infinite loop similar to this:

voidbar_optimized(void){foo=0;while(true);}

However, foo might represent a location that can be changed by other elements of the computer system at any time, such as a hardware register of a device connected to the CPU. The above code would never detect such a change; without the volatile keyword, the compiler assumes that the current program is the only part of the system that could change the value (which is by far the most common situation).

To prevent the compiler from optimizing code as above, the volatile keyword is used:

staticvolatileintfoo;voidbar(void){foo=0;while(foo!=255);}

With this modification the loop condition will not be optimized away, and the system will detect the change when it occurs.

Generally, there are memory barrier operations available on platforms (which are exposed in C++11) that should be preferred instead of volatile as they allow the compiler to perform better optimization and more importantly they guarantee correct behaviour in multi-threaded scenarios; neither the C specification (before C11) nor the C++ specification (before C++11) specifies a multi-threaded memory model, so volatile may not behave deterministically across OSes/compilers/CPUs). [5]

Optimization comparison in C

The following C programs, and accompanying assemblies, demonstrate how the volatile keyword affects the compiler's output. The compiler in this case was GCC.

While observing the assembly code, it is clearly visible that the code generated with volatile objects is more verbose, making it longer so the nature of volatile objects can be fulfilled. The volatile keyword prevents the compiler from performing optimization on code involving volatile objects, thus ensuring that each volatile variable assignment and read has a corresponding memory access. Without the volatile keyword, the compiler knows a variable does not need to be reread from memory at each use, because there should not be any writes to its memory location from any other thread or process.

C++11

According to the C++11 ISO Standard, the volatile keyword is only meant for use for hardware access; do not use it for inter-thread communication. For inter-thread communication, the standard library provides std::atomic<T> templates. [6]

In Java

The Java programming language also has the volatile keyword, but it is used for a somewhat different purpose. When applied to a field, the Java qualifier volatile provides the following guarantees:

Using volatile may be faster than a lock, but it will not work in some situations before Java 5 [8] . The range of situations in which volatile is effective was expanded in Java 5; in particular, double-checked locking now works correctly. [9]

In C#

In C#, volatile ensures that code accessing the field is not subject to some thread-unsafe optimizations that may be performed by the compiler, the CLR, or by hardware. When a field is marked volatile, the compiler is instructed to generate a "memory barrier" or "fence" around it, which prevents instruction reordering or caching tied to the field. When reading a volatile field, the compiler generates an acquire-fence, which prevents other reads and writes to the field, including those in other threads, from being moved before the fence. When writing to a volatile field, the compiler generates a release-fence; this fence prevents other reads and writes to the field from being moved after the fence. [10]

Only the following types can be marked volatile: all reference types, Single, Boolean, Byte, SByte, Int16, UInt16, Int32, UInt32, Char, and all enumerated types with an underlying type of Byte, SByte, Int16, UInt16, Int32, or UInt32. [11] (This excludes value structs, as well as the primitive types Double, Int64, UInt64 and Decimal.)

Using the volatile keyword does not support fields that are passed by reference or captured local variables; in these cases, Thread.VolatileRead and Thread.VolatileWrite must be used instead. [10]

In effect, these methods disable some optimizations usually performed by the C# compiler, the JIT compiler, or the CPU itself. The guarantees provided by Thread.VolatileRead and Thread.VolatileWrite are a superset of the guarantees provided by the volatile keyword: instead of generating a "half fence" (ie an acquire-fence only prevents instruction reordering and caching that comes before it), VolatileRead and VolatileWrite generate a "full fence" which prevent instruction reordering and caching of that field in both directions. [10] These methods work as follows: [12]

The Thread.VolatileRead and Thread.VolatileWrite methods generate a full fence by calling the Thread.MemoryBarrier method, which constructs a memory barrier that works in both directions. In addition to the motivations for using a full fence given above, one potential problem with the volatile keyword that is solved by using a full fence generated by Thread.MemoryBarrier is as follows: due to the asymmetric nature of half fences, a volatile field with a write instruction followed by a read instruction may still have the execution order swapped by the compiler. Because full fences are symmetric, this is not a problem when using Thread.MemoryBarrier. [10]

In Fortran

VOLATILE is part of the Fortran 2003 standard, [13] although earlier version supported it as an extension. Making all variables volatile in a function is also useful finding aliasing related bugs.

integer,volatile::i! When not defined volatile the following two lines of code are identicalwrite(*,*)i**2! Loads the variable i once from memory and multiplies that value times itselfwrite(*,*)i*i! Loads the variable i twice from memory and multiplies those values

By always "drilling down" to memory of a VOLATILE, the Fortran compiler is precluded from reordering reads or writes to volatiles. This makes visible to other threads actions done in this thread, and vice versa. [14]

Use of VOLATILE reduces and can even prevent optimization. [15]

Related Research Articles

In computing, an optimizing compiler is a compiler that tries to minimize or maximize some attributes of an executable computer program. Common requirements are to minimize a program's execution time, memory requirement, and power consumption.

This is a comparison of Java and C++, two prominent object-oriented programming languages.

In software engineering, double-checked locking is a software design pattern used to reduce the overhead of acquiring a lock by testing the locking criterion before acquiring the lock. Locking occurs only if the locking criterion check indicates that locking is required.

In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created. This is in contrast to a mutable object, which can be modified after it is created. In some cases, an object is considered immutable even if some internally used attributes change, but the object's state appears unchanging from an external point of view. For example, an object that uses memoization to cache the results of expensive computations could still be considered an immutable object.

This article compares two programming languages: C# with Java. While the focus of this article is mainly the languages and their features, such a comparison will necessarily also consider some features of platforms and libraries. For a more detailed comparison of the platforms, please see Comparison of the Java and .NET platforms.

A memory barrier, also known as a membar, memory fence or fence instruction, is a type of barrier instruction that causes a central processing unit (CPU) or compiler to enforce an ordering constraint on memory operations issued before and after the barrier instruction. This typically means that operations issued prior to the barrier are guaranteed to be performed before operations issued after the barrier.

Java syntax

The syntax of the Java programming language is the set of rules defining how a Java program is written and interpreted.

In the C, C++, D, and JavaScript programming languages, const is a type qualifier: a keyword applied to a data type that indicates that the data is read only. While this can be used to declare constants, const in the C family of languages differs from similar constructs in other languages in being part of the type, and thus has complicated behavior when combined with pointers, references, composite data types, and type-checking.

Thread-local storage (TLS) is a computer programming method that uses static or global memory local to a thread.

C++11 is a version of the standard for the programming language C++. It was approved by International Organization for Standardization (ISO) on 12 August 2011, replacing C++03, superseded by C++14 on 18 August 2014 and later, by C++17. The name follows the tradition of naming language versions by the publication year of the specification, though it was formerly named C++0x because it was expected to be published before 2010.

A property, in some object-oriented programming languages, is a special sort of class member, intermediate in functionality between a field and a method. The syntax for reading and writing of properties is like for fields, but property reads and writes are (usually) translated to 'getter' and 'setter' method calls. The field-like syntax is easier to read and write than lots of method calls, yet the interposition of method calls "under the hood" allows for data validation, active updating, or implementation of what may be called "read-only fields".

The Java memory model describes how threads in the Java programming language interact through memory. Together with the description of single-threaded execution of code, the memory model provides the semantics of the Java programming language.

The Java programming language and the Java virtual machine (JVM) have been designed to support concurrent programming, and all execution takes place in the context of threads. Objects and resources can be accessed by many separate threads; each thread has its own path of execution but can potentially access any object in the program. The programmer must ensure read and write access to objects is properly coordinated between threads. Thread synchronization ensures that objects are modified by only one thread at a time and that threads are prevented from accessing partially updated objects during modification by another thread. The Java language has built-in constructs to support this coordination.

Memory ordering describes the order of accesses to computer memory by a CPU. The term can refer either to the memory ordering generated by the compiler during compile time, or to the memory ordering generated by a CPU during runtime.

In computer programming, aliasing refers to the situation where the same memory location can be accessed using different names.

This article describes the syntax of the C# programming language. The features described are compatible with .NET Framework and Mono.

In computing, a memory model describes the interactions of threads through memory and their shared use of the data.

In computer programming, a constant is a value that cannot be altered by the program during normal execution, i.e., the value is constant. When associated with an identifier, a constant is said to be "named," although the terms "constant" and "named constant" are often used interchangeably. This is contrasted with a variable, which is an identifier with a value that can be changed during normal execution, i.e., the value is variable. Constants are useful for both programmers and compilers: For programmers they are a form of self-documenting code and allow reasoning about correctness, while for compilers they allow compile-time and run-time checks that verify that constancy assumptions are not violated, and allow or simplify some compiler optimizations.

OptimJ is an extension of the Java with language support for writing optimization models and abstractions for bulk data processing. The extensions and the proprietary product implementing the extensions were developed by Ateji which went out of business in September 2011. OptimJ aims at providing a clear and concise algebraic notation for optimization modeling, removing compatibility barriers between optimization modeling and application programming tools, and bringing software engineering techniques such as object-orientation and modern IDE support to optimization experts.

In the C, C++, and D programming languages, a type qualifier is a keyword that is applied to a type, resulting in a qualified type. For example, const int is a qualified type representing a constant integer, while int is the corresponding unqualified type, simply an integer. In D these are known as type constructors, by analogy with constructors in object-oriented programming.

References

  1. 1 2 "Publication on C++ standards committee".
  2. "Volatile Keyword In Visual C++". Microsoft MSDN.
  3. "Linux Kernel Documentation – Why the "volatile" type class should not be used". kernel.org.
  4. Scott Meyers; Andrei Alexandrescu (2004). "C++ and the Perils of Double-Checked Locking" (PDF). DDJ.
  5. Jeremy Andrews (2007). "Linux: Volatile Superstition". kerneltrap.org. Archived from the original on 2010-06-20. Retrieved Jan 9, 2011.
  6. "volatile (C++)". Microsoft MSDN.
  7. Section 17.4.4: Synchronization Order "The Java® Language Specification, Java SE 7 Edition". Oracle Corporation. 2013. Retrieved 2013-05-12.
  8. Jeremy Manson; Brian Goetz (February 2004). "JSR 133 (Java Memory Model) FAQ" . Retrieved 2019-11-05.
  9. Neil Coffey. "Double-checked Locking (DCL) and how to fix it". Javamex. Retrieved 2009-09-19.
  10. 1 2 3 4 Albahari, Joseph. "Part 4: Advanced Threading". Threading in C#. O'Reilly Media. Archived (PDF) from the original on 27 April 2011. Retrieved 9 December 2019.
  11. Richter, Jeffrey (February 11, 2010). "Chapter 7: Constants and Fields". CLR Via C#. Microsoft Press. p. 183. ISBN   978-0-7356-2704-8.
  12. Richter, Jeffrey (February 11, 2010). "Chapter 28: Primitive Thread Synchronization Constructs". CLR Via C#. Microsoft Press. pp. 797–803. ISBN   978-0-7356-2704-8.
  13. "VOLATILE Attribute and Statement". Cray.
  14. "Volatile and shared array in Fortran". Intel.com.
  15. "VOLATILE". Oracle.com.