5

InterlockedIncrement and other Interlocked operations declare their arguments as volatile. Why? What is the intention and effect of this?

Suma
  • 33,181
  • 16
  • 123
  • 191
  • I have found a heated debate about this http://groups.google.com/group/comp.programming.threads/tree/browse_frm/thread/1fa4a82dda916b18/a886def5998f9b82?rnum=21&_done=%2Fgroup%2Fcomp.programming.threads%2Fbrowse_frm%2Fthread%2F1fa4a82dda916b18%2Ffd6be8f0b18bd62d%3F#doc_5d933de5ad5378cf - no conclusion there, but there is detailed explanation of why volatile does not do what one would expect at first sight. – Suma Sep 14 '10 at 11:18
  • You might also want to look at the answers to [this question](http://stackoverflow.com/questions/3604569/what-kinds-of-optimizations-does-volatile-prevent-in-c). – sbi Sep 14 '10 at 13:10

4 Answers4

8

The probable effect is very minimal. The most likely intent is to allow users to pass volatile-qualified variables to these functions without the need for a typecast.

Bart van Ingen Schenau
  • 15,488
  • 4
  • 32
  • 41
4

This is done so that the function can be called both on normal variables and on volatile variables. You cannot pass a volatile variable into a function which is not expecting a volatile argument. The following code does not compile (tested with Visual Studio 2005 C++ compiler):

void TestV(int *a)
{
  *a = 1;
}

void Test()
{
  volatile int a = 0;
  TestV(&a);
}

With the declaration being what it is, you can do following:

volatile LONG a = 0;

InterlockedIncrement(&a);

As it most likely has a sense to call InterlockedIncrement on volatile variables, it seems sensible to have it declared as such.

Suma
  • 33,181
  • 16
  • 123
  • 191
0

The volatile argument prevents the compiler from making optimizations that prevent the read to memory. A compiler can make whatever optimizations it likes as long as the visible effects of the code are the same, but those effects aren't considered in multiple thread scenarios, only from a single thread. The volatile keyword tells the compiler that this variable may be modified or read from external, unknowable sources and the compiler cannot get rid of it or ellide memory accesses to it.

Puppy
  • 144,682
  • 38
  • 256
  • 465
  • 1
    This is true in general about volatile, but this is not applicable in this particular case. For the caller of the function, there is no difference if the function is handling the argument as volatile internally or not. – Suma Sep 14 '10 at 11:10
-2

In short, volatile means "this variable might be modified outside this program".

In a bit more words, it means that a variable's value can change without any related instructions in your code. It's often used in low-level I/O for instance, where the value of a register or buffer can be set by the hardware.

jv42
  • 8,521
  • 5
  • 40
  • 64
  • 1
    Does not seem applicable in this case. The compiler is not compiling the InterlockedIncrement function, and marking the variable as volatile has no effect outside of the function. – Suma Sep 14 '10 at 11:11
  • Sorry about that, I must have skipped a bit while reading your question. – jv42 Sep 14 '10 at 11:13
  • This have something to do with telling the compiler not to optimize the access to the variable, even inside the function. I'm not sure about why it is needed in the prototype, except to tell you how your parameters will be treated though. – jv42 Sep 14 '10 at 11:16
  • @Suma what do you mean "the compiler is not compiling the function"?? Surely some compiler did compile it _at some point_? – n00bmind Feb 14 '20 at 13:20