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)

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)

Yes and no. Volatile has basically never been useful for the exact situation "the object is modified by another POSIX or WIN32 thread of execution". That might be part of the spirit of the volatile keyword according to some, but the compiler, linker, and runtime implementors, with IIRC like one exception, have never implemented volatile to be useful in this example. There is no "etc". The exact list of where volatile is useful AFAIK in C/C++ is: signal handlers, MMIO, and longjmp. I would be highly suspect of any other proposed use. — Preceding unsigned comment added by 32.140.104.214 (talk) 11:25, 28 August 2024 (UTC)

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)

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)

I slightly updated and fixed the description of the busy-wait example. I don't think the example is wrong. What do you think is wrong about it? It is surely incomplete: it does not say how to make the volatile variable actually refer to some MMIO device. I added explicit language that this bit is missing from the example. However, from my limited knowledge of volatile in MMIO device drivers, this code is "correct". Having said that, maybe we should add another sentence saying something like: "Writing correct MMIO code with volatile is hard and often requires deep knowledge of the specific C/C++ implementation and platform that you are targeting." I am not competent to write a real MMIO device driver with volatile. However, I am competent to use volatile as part of sharing values with a signal handler and preserving values across a longjmp. 32.140.104.214 (talk) 11:33, 28 August 2024 (UTC)

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)

IMO, it should be kept because the meaning of the word "volatile" in programming has changed over time to include threading. I bet there are many more uses of volatile as a threading construct compared to MMIO, C longjmp, or C signal handlers. IMHO, we should document this current meaning of the word instead of focusing on certain esoteric academic computer science definitions. 32.140.104.214 (talk) 11:29, 28 August 2024 (UTC)

I took a try at fixing some of the more obvious problems with the article. I don't know C# or Fortran, and so I left those sections alone. (I'm the same person who long long ago added the 3 or 4 citations that volatile is not a useful multi-threading construct in C/C++.) — Preceding unsigned comment added by 32.140.104.214 (talk) 11:20, 28 August 2024 (UTC)

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)

I just clarified the example to be a memory-mapped IO example, which is typically a correct use of volatile in C/C++. You are correct that using volatile in C/C++ for communication between threads is usually (almost always?) wrong.

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)

Yes. You can have a pointer to volatile int, and a volatile pointer to (non-volatile) int, and a volatile pointer to volatile int. — Preceding unsigned comment added by 32.140.104.214 (talk) 11:22, 28 August 2024 (UTC)

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)

The three canonical correct uses of volatile in C/C++ are signal handlers, setjmp longjmp, and and MMIO. Yours is clearly the signal handler use case. (Using volatile in C/C++ in anything other than one of these three canonical use cases is almost certainly incorrect.) 32.140.104.214 (talk) 11:36, 28 August 2024 (UTC)

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:

1. I'd say the use of signal is a fairly obvious use of a "setjmp", whether or not the actual routine setjmp is called.
2. 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)

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)

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

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)

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)

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)

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)

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)

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)

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)

Use of volatile in multithreading

"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)