| |||||||||||||
|
| |||||||||||||
The trouble with volatileThe trouble with volatilePosted May 12, 2007 3:46 UTC (Sat) by mikov (subscriber, #33179)Parent article: The trouble with volatile
There have been some very fun discussions about volatile on comp.std.c in the past. Basically my opinion, although I have never been able to convince anybody, is that volatile is _always_ wrong even in user mode. Period. It serves no purpose whatsoever that couldn't be achieved much better and more reliably in a different way. To put it another way, volatile is useless in a 100% standard-compliant C program, and if the program is not 100% compliant, then it is even more useless.
Also, not all compilers implement it. Notably Borland C in some of its versions didn't.
People might argue that it is useful with signals or longjmp(), but the need for volatile in such scenarios is always an indication of a serious problem in the code.
The way I find it easy to think about it or explain it is that volatile does nothing to prevent the CPU reordering memory accesses, not to mention the visibility of memory accesses across different CPUs. So, it just muddles the issues.
I want to open a big bracket here and mention that volatile in Java an entirely different beast and is much much more useful. According to the Java memory model, volatile actually has very useful guarantees for memory visibility. (Perhaps Linux should consider Java for the kernel :-)
Still, I agree with what already has already been said earlier: it is conceptually wrong to mark data as volatile. Accesses should be marked, bit the data itself. So, Java doesn't get it 100% right either. (But of course it wasn't possible to add lightweight volatile accesses to Java without modifying the language).
(Log in to post comments)
The trouble with volatile Posted May 14, 2007 15:07 UTC (Mon) by BenHutchings (subscriber, #37955) [Link] "People might argue that it is useful with signals or longjmp(), but the need for volatile in such scenarios is always an indication of a serious problem in the code."
These are the two cases defined by the standard where volatile *must* be used for certain variables. Memory-mapped I/O is the third case it was intended for, but as that's inherently unportable the standard doesn't explicitly mention it. (I think the rationale does.)
The trouble with volatile Posted May 14, 2007 17:30 UTC (Mon) by mikov (subscriber, #33179) [Link] You are right. IIRC, it is required for local variables with setjmp(). I forgot the other case. What was it ? (Hmm, I have my C99 standard somewhere here..)
In any case, it doesn't mean that it actually is a good idea. Requiring volatile for setjmp() is a terrible, fragile, ugly hack. It's been some time since I thought about this, but off the top of my head:
This requirement presumes that the compiler doesn't know anything about setjmp()/longjmp(). What if the function invoking setjmp() gets auto-inlined ? Obviously the programmer can't be required to use volatile for all variables in all functions up the call tree. What is to prevent the auto-inlining ?
I don't view the standard as a mantra. After all, it did standardize "atoi" ... There is no excuse for that. There are things in the C99 that strike me as absolutely horrible.
The trouble with volatile Posted May 16, 2007 8:38 UTC (Wed) by roelofs (subscriber, #2599) [Link] The way I find it easy to think about it or explain it is that volatile does nothing to prevent the CPU reordering memory accesses, not to mention the visibility of memory accesses across different CPUs.Well, more generally, the C and C++ languages themselves do nothing to prevent such problems (unlike Java)--they are blissfully unaware of all concurrency-related issues, and as a consequence, there is nothing you can do about any of it using only language-provided constructs. Some form of assembly-level support is always required. Note that, fundamentally, it's the same problem afflicting the Double-Checked Locking Pattern (C/C++ version). Scott Meyers' (co-authored) 2004 DDJ article describes the issues quite nicely. Greg
The trouble with volatile Posted May 16, 2007 11:48 UTC (Wed) by massimiliano (subscriber, #3048) [Link] I want to open a big bracket here and mention that volatile in Java an entirely different beast and is much much more useful. According to the Java memory model, volatile actually has very useful guarantees for memory visibility. (Perhaps Linux should consider Java for the kernel :-) Or C#... it seems that the .NET platform is even more specific than Java in this sense :-)
|
|
||||||||||||