Volatile (computer programming)

Last updated

In computer programming, a volatile value is a value that can be asynchronously read by something else or asynchronously changed by something else while the current code is running.

Contents

Despite being a common keyword across many programming languages, the behavior of the volatile keyword differs in subtle and important ways between the several programming languages that have it. The common theme is that a volatile variable is a variable that may be read or modified by something outside of the current thread of execution while the current thread is running. In particular, the value of a volatile variable may spontaneously change without any possible cause from the code in the current thread, and sometimes a volatile variable may spontaneously change without any possible cause from any code in the whole program. The typical reasons to use volatile include: accessing hardware devices via memory-mapped I/O (where you can send and receive messages from peripheral devices by reading from and writing to memory), sharing values with asynchronous signal handlers, and sharing values with other threads of execution. Support for these use cases varies considerably among the several programming language that have the volatile keyword.

Volatility can have implications regarding function calling conventions and how variables are stored, accessed and cached.

In C and C++

In C and C++, volatile is a type qualifier, like const , and is a part of a type (e.g. the type of a variable or field).

The behavior of the volatile keyword in C and C++ is sometimes given in terms of suppressing optimizations of an optimizing compiler: 1- don't remove existing volatile reads and writes, 2- don't add new volatile reads and writes, and 3- don't reorder volatile reads and writes. However, this definition is only an approximation for the benefit of new learners, and this approximate definition should not be relied upon to write real production code.

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

The C and C++ standards allow writing portable code that shares values across a longjmp in volatile objects, and the standards allow writing portable code that shares values between signal handlers and the rest of the code in volatilesig_atomic_t objects. Any other use of volatile keyword in C and C++ is inherently non-portable or incorrect. In particular, writing code with the volatile keyword for memory-mapped I/O devices is inherently non-portable and always requires deep knowledge of the specific target C/C++ implementation and platform.

Multi-Threading

It is a common misconception that the volatile keyword is useful in portable multi-threading code in C and C++. The volatile keyword in C and C++ has never functioned as a useful, portable tool for any multi-threading scenario. [2] [3] [4] [5] Unlike the Java and C# programming languages, operations on volatile variables in C and C++ are not atomic, and operations on volatile variables do not have sufficient memory ordering guarantees (i.e. memory barriers). Most C and C++ compilers, linkers, and runtimes simply do not provide the necessary memory ordering guarantees to make the volatile keyword useful for any multi-threading scenario. Before the C11 and C++11 standards, programmers were forced to rely on guarantees from the individual implementations and platforms (e.g. POSIX and WIN32) to write multi-threading code. With the modern C11 and C++11 standards, programmers can write portable multi-threading code using new portable constructs such as the std::atomic<T> templates. [6]

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, the programmer may make foo refer to another element of the computer system such as a hardware register of a device connected to the CPU which may change the value of foo while this code is running. (This example does not include the details on how to make foo refer to a hardware register of a device connected to the CPU.) Without the volatile keyword, an optimizing compiler will likely convert the code from the first sample with the read in the loop to the second sample without the read in the loop as part of the common loop-invariant code-motion optimization, and thus the code will likely never notice the change that it is waiting for.

To prevent the compiler from doing this optimization, the volatile keyword can be used:

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

The volatile keyword prevents the compiler from moving the read out of the loop, and thus the code will notice the expected change to the variable foo.

Optimization comparison in C

The following C programs, and accompanying assembler language excerpts, 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.

Standards Defects

While intended by both C and C++, the current C standard fails to express that the volatile semantics refer to the lvalue, not the referenced object. The respective defect report DR 476 (to C11) is still under review with C17. [7]

Compiler Defects

Unlike other language features of C and C++, the volatile keyword is not well supported by most C/C++ implementations - even for portable uses according to the C and C++ standards. Most C/C++ implementations are buggy regarding the behavior of the volatile keyword. [8] [9] Programmers should take great care whenever using the volatile keyword in C and C++.

In Java

In all modern versions of the Java programming language, the volatile keyword gives the following guarantees:

Together, these guarantees make volatile into a useful multi-threading construct in Java. In particular, the typical double-checked locking algorithm with volatile works correctly in Java. [12]

Very Old Versions Of Java

Before Java version 5, the Java standard did not guarantee the relative ordering of volatile and non-volatile reads and writes. In other words, volatile did not have "acquire" and "release" memory barrier semantics. This greatly limited its use as a multi-threading construct. In particular, the typical double-checked locking algorithm with volatile did not work correctly.

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 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. [13]

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. [14] (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. [13]

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. [13] These methods work as follows: [15]

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. [13]

In Fortran

VOLATILE is part of the Fortran 2003 standard, [16] 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. [17]

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

Related Research Articles

Dekker's algorithm is the first known correct solution to the mutual exclusion problem in concurrent programming where processes only communicate via shared memory. The solution is attributed to Dutch mathematician Th. J. Dekker by Edsger W. Dijkstra in an unpublished paper on sequential process descriptions and his manuscript on cooperating sequential processes. It allows two threads to share a single-use resource without conflict, using only shared memory for communication.

Java and C++ are two prominent object-oriented programming languages. By many language popularity metrics, the two languages have dominated object-oriented and high-performance software development for much of the 21st century, and are often directly compared and contrasted. Java's syntax was based on C/C++.

In multi-threaded computer programming, a function is thread-safe when it can be invoked or accessed concurrently by multiple threads without causing unexpected behavior, race conditions, or data corruption. As in the multi-threaded context where a program executes several threads simultaneously in a shared address space and each of those threads has access to every other thread's memory, thread-safe functions need to ensure that all those threads behave properly and fulfill their design specifications without unintended interaction.

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 (OO) 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.

<span class="mw-page-title-main">C syntax</span> Set of rules defining correctly structured programs

The syntax of the C programming language is the set of rules governing writing of software in C. It is designed to allow for programs that are extremely terse, have a close relationship with the resulting object code, and yet provide relatively high-level data abstraction. C was the first widely successful high-level language for portable operating-system development.

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, see Comparison of the Java and .NET platforms.

In computing, 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.

In some programming languages, const is a type qualifier 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 that it is part of the type, and thus has complicated behavior when combined with pointers, references, composite data types, and type-checking. In other languages, the data is not in a single memory location, but copied at compile time for each use. Languages which use it include C, C++, D, JavaScript, Julia, and Rust.

In computer programming, thread-local storage (TLS) is a memory management method that uses static or global memory local to a thread. The concept allows storage of data that appears to be global in a system with separate threads.

In the Java programming language, the final keyword is used in several contexts to define an entity that can only be assigned once.

C++11 is a version of the ISO/IEC 14882 standard for the C++ programming language. C++11 replaced the prior version of the C++ standard, called C++03, and was later replaced by C++14. 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.

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) is designed to support concurrent programming. 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 prevents threads from accessing partially updated objects during modification by another thread. The Java language has built-in constructs to support this coordination.

Memory ordering is the order of accesses to computer memory by a CPU. Memory ordering depends on both the order of the instructions generated by the compiler at compile time and the execution order of the CPU at runtime. However, memory order is of little concern outside of multithreading and memory-mapped I/O, because if the compiler or CPU changes the order of any operations, it must necessarily ensure that the reordering does not change the output of ordinary single-threaded code.

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 is not altered by the program during normal execution. 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. To simplify, constants' values remains, while the values of variables varies, hence both their names.

a type qualifier is a analogy with constructors in object-oriented programming.

References

  1. "Publication on C++ standards committee".
  2. "Volatile Keyword In Visual C++". Microsoft MSDN. 21 September 2021.
  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. 21 September 2021.
  7. Clarification Request Summary for C11. Version 1.13, October 2017.
  8. Eide, Eric; Regehr, John (October 2008). "Volatiles Are Miscompiled, and What to Do about It" (PDF). Proceedings of the Eighth ACM and IEEE International Conference on Embedded Software (EMSOFT), Atlanta, Georgia, USA via cs.utah.edu.
  9. "Volatile Bugs, Three Years Later – Embedded in Academia". blog.regehr.org. Retrieved 2024-08-28.
  10. Section 17.4.4: Synchronization Order "The Java® Language Specification, Java SE 7 Edition". Oracle Corporation. 2013. Retrieved 2013-05-12.
  11. "Java Concurrency: Understanding the 'Volatile' Keyword". dzone.com. 2021-03-08. Archived from the original on 2021-05-09. Retrieved 2021-05-09.
  12. Neil Coffey. "Double-checked Locking (DCL) and how to fix it". Javamex. Retrieved 2009-09-19.
  13. 1 2 3 4 Albahari, Joseph. "Part 4: Advanced Threading". Threading in C#. O'Reilly Media. Archived from the original on 12 December 2019. Retrieved 9 December 2019.{{cite web}}: CS1 maint: bot: original URL status unknown (link)
  14. Richter, Jeffrey (February 11, 2010). "Chapter 7: Constants and Fields". CLR Via C# . Microsoft Press. pp.  183. ISBN   978-0-7356-2704-8.
  15. 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.
  16. "VOLATILE Attribute and Statement". Cray. Archived from the original on 2018-01-23. Retrieved 2016-04-22.
  17. "Volatile and shared array in Fortran". Intel.com.
  18. "VOLATILE". Oracle.com.