Talk:Volatile (computer programming)

Example in C

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)[reply]

may be modified externally from the declaring object

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)[reply]

needs to be rewritten

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)[reply]

questionable link to busy waiting for example

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)[reply]

volatile pointer

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)[reply]

Another example

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)[reply]

Not to mention that in the example "foo" can not be changed by a different thread since it is static.

Far too late for this to be of use, but for posterity:

I'd say the use of signal is a fairly obvious use of a "setjmp", whether or not the actual routine setjmp is called.
The fact that 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)[reply]

Programming language

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)[reply]

C# also has volatile, which the article fails to mention. L337 Krew (talk) 08:35, 17 July 2009 (UTC)[reply]

Volatility Is Not A Programming Language Issue

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:

In computer programming, a variable in a program is called volatile if its value can change by means other than the execution of that program. This typically occurs when the variable is allocated to memory that can be changed by hardware action, either by the CPU or some external device. For example, in a VME environment, special-purpose boards often make some of their local memory visible in the VME address space; this shared memory can be used to transfer data between the board and the main CPU or to determine the state of the on-board program.

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)[reply]

While I'm vaguely inclined to agree with you, I think it's quite clear this is discussing the volatile keyword in certain languages. Perhaps an article title move is appropriate.

I don't know that "hardware action" is a good phrase there, in the sense that it does not cover – at least not without stretching meanings – multiple threads/processes/whatevers accessing the same memory location. That is in a sense a hardware action of course (everything is, ultimately), but from the point of view of this article is a software action. Also, some bus locations may be memory-mapped I/O and so forth, and not "memory locations" in the sense I think you imply here. Si Trew (talk) 22:24, 19 July 2010 (UTC)[reply]

Code Generation Effect Is Over-Emphasized

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)[reply]

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)[reply]

What's the CPU?

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)[reply]

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)[reply]

Disassembly

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)[reply]