I know the purpose of keyword but then I still not really know when should i use. But I sure I will optimize my code. So is it ok to i use volatile keyword on all my variables? So that it won't optimize the wrong thing.
murnesty 0 Junior Poster in Training
mike_2000_17 2,669 21st Century Viking Team Colleague Featured Poster
First of all, there is no point in using the volatile keyword on a variable that is not shared between more than one thread. The whole idea of a volatile variable is to tell the compiler that this variable could change value at anytime, in parallel to the thread of execution (e.g. by another thread or process). If that is never going to happen (e.g. the variable is local to the thread or its stack-frame), then there is absolutely no point in using that keyword, it would be a pessimization (contrary to optimization). And stand assured, it will make absolutely no difference behavior-wise (e.g. on the results) except for the longer execution time.
So, the effect of the volatile keyword is that if you have, in a function, two lines that invoke the given variable (e.g. read its value), the compiler is not allowed to assume that both invocations of the variable will result in the same value being read (which would normally always be the case if, in that function, nothing modifies the value, and if there is no other thread or process that could modify the value).
So, assume you have a global variable (or something similar) which could be accessed and modified by multiple threads concurrently. In this case, it would make sense to have it declared volatile. However, the story doesn't end there. For it to make sense to use volatile, you also need the variable to have atomic operations. This means that any read / write operations on the variable must be an indivisible operation (put simply, a single CPU instruction). So, fundamental types, like int or float, would, in most architectures, be dealt with atomically. For non-fundamental types (e.g. classes), this would rarely be the case, unless it was specifically designed to provide atomic operations. The new C++11 standard also introduces library facilities to make atomic operations on custom classes, however, I don't think that many compilers support this feature just yet (maybe ICC).
If the variable in question cannot be guaranteed to have atomic operations, then accessing it from multiple threads without using a mutual exclusion (mutex) scheme is going to be dangerous no matter what (volatile or not). In this case, you must use a mutex to protect the access to that variable or resource. At this point, the volatile keyword will have no effect (because of the increased complexity in performing read / write operations, the volatile keyword will just tell the compiler not to do optimizations that it would not be able to do anyways).
Conclusion: If you have a single variable with atomic read / write operations, which is changing frequently, and shared among different threads, then you should use the volatile keyword, as a matter of correctness (to get the expected behaviour or correct results). In any other case (i.e. non-atomic, constant or quasi-constant, or not shared), it is either useless or a pessimization to use the volatile keyword.
So, to answer your question, it depends. It is stupid to declare all your variables as volatile, especially local variables (variables declared inside a function). But it is OK to do so from a point of view of correctness (i.e. it will work, but it should make no difference, except on variables that meet the above criteria).
Be a part of the DaniWeb community
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.