Volatile in C
Volatile keyword says the compiler that no optimiztion on the variable.
The volatile keyword acts as a data type qualifier.
The volatile qualifier alters the default behaviour of the variable and does not attempt to optimize the storage referenced by it.
- Martin Leslie
volatile means the storage is likely to change at anytime and be changed but something outside the control of the user program. This means that if you reference the variable, the program should always check the physical address (ie a mapped input fifo), and not use it in a cacheed way.
- Stephen Hunt
Syntax Volatile
volatile datatype variable;
To declare a variable volatile, include the keyword volatile before or after the data type in the variable definition. For instance both of these declarations will declare foo to be a volatile integer:
volatile int foo;
int volatile foo;
Now, it turns out that pointers to volatile variables are very common. Both of these declarations declare foo to be a pointer to a volatile integer:
volatile int * foo;
int volatile * foo;
Volatile pointers to non-volatile variables are very rare (I think I’ve used them once), but I’d better go ahead and give you the syntax:
int * volatile foo;
And just for completeness, if you really must have a volatile pointer to a volatile variable, then:
int volatile * volatile foo;
Finally, if you apply volatile to a struct or union, the entire contents of the struct/union are volatile. If you don’t want this behavior, you can apply the volatile qualifier to the individual members of the struct/union.
Use of volatile variable
A variable should be declared volatile whenever its value could change unexpectedly.
We use volatile variables in
• Memory-mapped peripheral registers.
• Global variables modified by an interrupt service routine.
• Global variables within a multi-threaded application
References
Jones, Nigel. “Introduction to the Volatile Keyword” Embedded Systems Programming, July 2001
Comments
6 Responses to “Volatile in C”
Leave a Reply
This tutorial is really good, giving clear explanation of what “volatile” means in C programming…
The reason for having volatile qualifier is mainly to do with the problems that are encountered in real-time or embedded systems programming using C. Imagine that you are writing code that controls a hardware device by placing appropriate values in hardware registers at known absolute addresses.
most C compilers have been unable to make that sort of optimization in the past. To remove the problem (and other similar ones to do with when to write to where a pointer points), the keyword volatile was introduced. It tells the compiler that the object is subject to sudden change for reasons which cannot be predicted from a study of the program itself, and forces every reference to such an object to be a genuine reference.
Volatile is also needed in threaded code when you are playing with data that isn’t concurrency protected. And yes there are valid times to be doing that, you can for example write a thread safe circular message queue without needing explicit concurrency protection, but it will need volatiles.
The volatile keyword was devised to prevent compiler optimizations that might render code incorrect in the presence of certain asynchronous events. For example, if you declare a primitive variable as volatile, the compiler is not permitted to cache it in a register — a common optimization that would be disastrous if that variable were shared among multiple threads. So the general rule is, if you have variables of primitive type that must be shared among multiple threads, declare those variables volatile. But you can actually do a lot more with this keyword: you can use it to catch code that is not thread safe, and you can do so at compile time. This article shows how it is done; the solution involves a simple smart pointer that also makes it easy to serialize critical sections of code.
When writing multithreaded programs, you can use volatile to your advantage. You must stick to the following rules:
1.Define all shared objects as volatile.
2.Don’t use volatile directly with primitive types.
3.When defining shared classes, use volatile member functions to express thread safety.
If you do this, and if you use the simple generic component LockingPtr, you can write thread-safe code and worry much less about race conditions, because the compiler will worry for you and will diligently point out the spots where you are wrong.