This is the
talk page for discussing improvements to the
Volatile (computer programming) article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||
|
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)
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.
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.
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)
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)
Without use of the keyword "volatile" the following program - if optimized - will likely just print "value=0" because the code incrementing "value" is just optimized away. This is a somewhat interesting case because it does not involve an external modifier, special memory and no (obvious use of) setjmp.
#include <stdlib.h> #include <stdio.h> #include <signal.h> #include <unistd.h> static volatile sig_atomic_t value; static void sighandler(int sig) { (void) sig; printf("value=%u\n", (unsigned) value); exit(EXIT_SUCCESS); } static void increment(void) { for (;;) value++; } int main(void) { signal(SIGALRM, sighandler); alarm(1); increment(); return 0; }
-- 82.141.49.88 02:38, 11 March 2007 (UTC)
Not to mention that in the example "foo" can not be changed by a different thread since it is static.
signal
is a fairly obvious use of a "setjmp", whether or not the actual routine setjmp
is called.foo
(by which I presume you mean value
) is static
does not stop it being accessed by another thread, since static
defines static storage and (here) file-level lexical scope, not dynamic access. It could be modified through a pointer, for example.
Si Trew (
talk)
22:30, 19 July 2010 (UTC)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)
C# also has volatile, which the article fails to mention. L337 Krew ( talk) 08:35, 17 July 2009 (UTC)
I look at volatile variables as a programming issue, not a language issue. Languages come into play only as they address this issue. Therefore, I suggest that the opening section be something like this:
The subsequent sections can then be used to discuss programming language support, the inadequacy of volatile variables in thread synchronization, etc. SDCHS ( talk) 17:26, 19 May 2010 (UTC)
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)
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)
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)
"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)
This is the
talk page for discussing improvements to the
Volatile (computer programming) article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||
|
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)
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.
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.
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)
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)
Without use of the keyword "volatile" the following program - if optimized - will likely just print "value=0" because the code incrementing "value" is just optimized away. This is a somewhat interesting case because it does not involve an external modifier, special memory and no (obvious use of) setjmp.
#include <stdlib.h> #include <stdio.h> #include <signal.h> #include <unistd.h> static volatile sig_atomic_t value; static void sighandler(int sig) { (void) sig; printf("value=%u\n", (unsigned) value); exit(EXIT_SUCCESS); } static void increment(void) { for (;;) value++; } int main(void) { signal(SIGALRM, sighandler); alarm(1); increment(); return 0; }
-- 82.141.49.88 02:38, 11 March 2007 (UTC)
Not to mention that in the example "foo" can not be changed by a different thread since it is static.
signal
is a fairly obvious use of a "setjmp", whether or not the actual routine setjmp
is called.foo
(by which I presume you mean value
) is static
does not stop it being accessed by another thread, since static
defines static storage and (here) file-level lexical scope, not dynamic access. It could be modified through a pointer, for example.
Si Trew (
talk)
22:30, 19 July 2010 (UTC)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)
C# also has volatile, which the article fails to mention. L337 Krew ( talk) 08:35, 17 July 2009 (UTC)
I look at volatile variables as a programming issue, not a language issue. Languages come into play only as they address this issue. Therefore, I suggest that the opening section be something like this:
The subsequent sections can then be used to discuss programming language support, the inadequacy of volatile variables in thread synchronization, etc. SDCHS ( talk) 17:26, 19 May 2010 (UTC)
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)
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)
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)
"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)