First some resources from the web,
The colin walls blog (http://blogs.mentor.com/colinwalls/blog/2009/08/31/volatile/),
There is one feature of C/C++, that is often not well understood, but is a godsend to embedded programmers: the keyword volatile …
When you declare a variable/object volatile, you are telling the compiler not to optimize access to the data. When your code writes a value to the variable, it should be written straight away and not saved in a register for use later. Likewise, when the code reads the value, it should not use a copy that was obtained earlier.
Broadly speaking, it must be assumed that a volatile variable can change at any time, independently of the current code. This implies two uses: variables that are shared between execution threads [between tasks in an RTOS or between the mainline code and an interrupt service routine]; I/O device registers.
Although volatile is a useful language facility, it is not without difficulties. Firstly, some research has shown that many compilers do not implement the keyword correctly in all circumstances. So care and attention to generated code is required. There are also the usual troubles with C syntax; consider these:
volatile int* pi1 = 0; // pointer to volatile int
int* volatile pi2 = 0; // volatile pointer to int
volatile int* volatile pi3 = 0; // volatile pointer to volatile int
Plenty of room for errors there! [The same syntactic issues arise with const.]
However, just declaring a variable volatile is not enough if you are sharing it between execution threads [even if there are texts that suggest that this is the case]. To illustrate the problem, consider this code:
volatile x = 1;
...
x++;
Syntactically this is fine, but what about the generated code? If the CPU instruction set allows a memory location to be incremented directly with a single, non-interruptible instruction, there is no problem [so long as the compiler uses those instructions!]. But many devices would require the data to be read, incremented and written back. This is all fine according to the language definition, but what if an interrupt occurs during this sequence of instructions?
You need to protect access to it so that the memory location always contains a valid value. You could do this by disabling and re-enabling interrupts or, with an RTOS, maybe a semaphore would be the answer.
I had to re-read this multiple times to understand what exactly it means. So when we define a variable volatile,
-> We are telling compiler to do always read that variable from memory, it should not do any optimization like storing in a register or optimize the code assuming it being a deadcode.
-> volatile is not storage specifier, i.e. it doesn't specify where the variable would be stored.
-> volatile can not control the way the caching is done in the system. Caching is controlled by the way we define in the pages in page table during linking stage.
