Talk:Volatile (computer programming)

message: This section seems to be copied from an Intel related book (the word 'book' appears in the text and there is a reference to a PXA CPU)  — Preceding unsigned comment added by 190.192.128.215 (talk) 19:50, 6 July 2012 (UTC)
thread_title:  Example in C 

message: This is complete gibberish.
What volatile means in C is that an object may be modified from an alternate execution context.
e.g., a signal handler, a longjmp, a thread, shared memory, a device or whatever.
:Indeed, also "Variables declared to be volatile will not be optimized by the compiler" should say something more like, "Certain optimizations cannot take place on the code which uses the variable".  —Preceding unsigned comment added by 99.224.115.100 (talk) 17:30, 14 April 2010 (UTC)
thread_title:  may be modified externally from the declaring object 

message: This article needs to be completely rewritten for the following reasons:
1) It confuses the problem of reading stale data with the problem of concurrent access. For example, it suggests that mutual exclusion is an alternative to using 'volatile'.
2) It fails to mention the two things that 'volatile' is actually both necessary and sufficient for, code that might be interrupted by a signal and code that uses 'longjmp'.
3) It talks about behavior that might happen to be true on some particular implementation as if it was guaranteed behavior.
4) It fails to mention that 'volatile' contains no atomicity guarantees whatsoever (except for reads of sig_atomic_t variables on single-threaded programs). So even if it guarantees that a change is noticed, it does not guarantee that the right value is read. (Rather than some bits of the old value and some of the new.) Foolishly, the example does not use 'sig_atomic_t'!
No solution short of rewriting will address these problems, IMO.
:I agree that this need rewriting, but my concern is that it has a thrown-together feel.  (This might have been the intention of the original writer: to just get something out there in order to begin a discussion.)  In particular, the section structure has no flow.  For example, I envision a section on programming language approaches to addressing the issue with a subsection for each programming language discussed.  Another would be a section on code generation issues (small, as I've argued elsewhere) with a subsection for each issue.
:As to errors and omissions, I doubt that anyone will get it entirely correct on his first try.  That's why Wikipedia articles can always be edited.  SDCHS (talk) 18:04, 19 May 2010 (UTC)
replies: text: The only option other than a complete rewrite is removal. This code, and the code under the entry for Busy_Wait, is broken. It is reckless to leave this here, even dangerous. Some programmer might think it is accurate. People use this stuff to control machinery, even spacecraft. The subject is tricky. Even bullet point number 2 above is incorrect. Volatile has meaning and usefulness on systems that do not have signals or longjmps. The variable might not even be a variable as we think of them. It might be a machine register or something memory-mapped that is altered or inspected by a completely different machine! Jive Dadson (talk) 03:25, 19 August 2012 (UTC)

text: The C# section mentions memory barriers, which have more to do with atomicity than volatility. This further confuses what's already a blurry issue (that people think volatile variables are inherently atomic). While forcing any earlier loads to complete before the barrier has something to do with volatility (vaguely), directly accessing volatile variables (as opposed to loading them into the local scope) means that the memory barrier reference is pointless. I think it should be removed as volatility is a confusing enough concept for people and this just adds to that. Leon.momirov (talk) 09:05, 4 September 2012 (UTC)
thread_title:  needs to be rewritten 

message: The article links to busy waiting for an example of volatile in use: "For an example of the use of volatile in context, see Busy waiting."
However, this is immediately followed by these statements:
1) Note that using volatile as a threading primitive is not guaranteed to work in C, C++, or Java versions 1 to 1.4. There are many systems where it will not.
2) In C and C++, volatile was not intended, and it is not implemented on all systems, to be a correct or useful synchronization primitive.
The example currently up on the busy waiting page DOES appear to be using the volatile variable as a threading primitive for synchronization; either the link to the busy waiting example should be removed, or an explanation should be given as to why it is okay for volatile variables to be used for synchronization in the example code. (From my rudimentary understanding, I don't think that the example code is, in fact, safe.)
134.173.66.78 (talk) 03:12, 30 January 2009 (UTC)
thread_title:  questionable link to [[busy waiting]] for example 

message: Does C support volatile pointers? I does not mean pointers to volatile data. Same as const pointers (and pointer to constants). --89.49.193.114 20:35, 11 February 2007 (UTC)
thread_title:  volatile pointer 

message: It would make sense to mention which programming languages support this feature. The article talks about it as if it were something universal. --CyHawk (talk) 19:45, 22 October 2008 (UTC)
thread_title:  Programming language 

message: While a short section on the impact of volatility on code generation might be justified, in the current write-up it's receiving far too much emphasis.  A reader first coming to this subject here might come away with the impression that the purpose of declaring a variable to be volatile is to thwart a compiler optimizer, for some strange reason.  In reality, of course, a compiler is required to generate code that works given the information it has from the source code (and elsewhere).  The effect on register optimization is a consequence of this.  Register optimization can't be used because it would be incorrect for the compiler to assume at any point that the variable's value is in a register.
Simultaneous with arguing that code generation issues should be downplayed, I point out that one that has not been discussed so far is the effect of volatility on machines with cached memory.  In most (all?) of those, it is necessary to spoil the cache to ensure that the variable's value is fetched from memory, not a cache. SDCHS (talk) 17:47, 19 May 2010 (UTC)
replies: text: I was thinking along the same lines about cacheing. I kinda assumed it was in one of the references, but it should be called out, yes. Si Trew (talk) 22:20, 19 July 2010 (UTC)
thread_title:  Code Generation Effect Is Over-Emphasized 

message: The longish section titled "Optimization comparison in C" doesn't identify the CPU being used.  I suspect it's the latest Intel flavor but I'm not sure.  I haven't worked with Intel in something like 25 years, believe it or not, and I think there might be a few more equally ignorant folks out there.  SDCHS (talk) 18:14, 19 May 2010 (UTC)
replies: text: I'd say it was 32-bit x86 code. I'm ancient enough to still prefer the way Intel write the disassembly to the way GCC does it. (Actually Intel offers both options, and for fun, they put the source/destination in binary operations in a different order!) Si Trew (talk) 22:18, 19 July 2010 (UTC)
thread_title:  What's the CPU? 

message: Much as I like reading a bit of assembler language now and again, does the disassembly section really add anything? Either you understand the disassembly and that it's not optimizing register/memory access, or you don't. Do we really need to show that longhand? Si Trew (talk) 22:15, 19 July 2010 (UTC)
thread_title:  Disassembly 

message: "Volatile values primarily arise in hardware access (memory-mapped I/O), where reading from or writing to memory is used to communicate with peripheral devices, and in threading, where a different thread may have modified a value."
This needs to specify this is for java only. For C/C++ volatile is not used for multithreading.  — Preceding unsigned comment added by 24.98.232.96 (talk) 01:55, 2 July 2015 (UTC)
thread_title:  Use of volatile in multithreading