Volatile + multithreading

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Is volatile really of any use with the current compilers VS 2003?

The only time I think volatile may do something on code is if it is used on
a parameter value or on a method variable. Using volatile on any class
field or global seems to have no impact because it seems the compiler will
never not read or write the variable directly from memory for any variable
that is not a parameter variable or a method variable.

Thinking more closely on this it kind of makes sense otherwise all
multithreaded code would potentially be in jeopardy. Think what would
happen if you really did have to apply volatile to avoid a variable being
put into a register. In multithreaded code that would many virtually any
variable you use that you access from another thread would require having
volatile applied. locks, and locking do not protect you, as the compiler
doesn't know anything about lock calls (even if it did, it wouldn't matter
because if you called a locking/synchronization object indirectly through a
virtual members or just multiple calls there is no way it would know there
could be an issue until runtime which is too late.)

think of a case where I do the following.
class MyClass
{
bool m_bDone;

MyMethod()
{
//What if compiler put m_bDone in register AX here
AcquireCriticalSection()
while(!m_bDone) //What happens if m_bDone was preloaded in a register
earlier and now this is while(!AX)

{
//Do work here
}
ReleaseCriticalSection();
}

//.. Other methods here

}

This means that locks would not protect you, only the keyword volatile
would. This would require you to put volatile on every variable used in a
way that mattered.

It seems the compiler writers must have known this and instead imposed the
rule that only parameter variables and stack variables (method variables)
can be optimized into registers since no one is likely to pass the address
to one of those to be used by another thread. This I believe prevents a
majority of the multithreading issues that could have resulted from
optimization. I thought there might be a compiler option that would
optimize this so you would require this. It seems there is a compiler option
for aliasing that seems to suggest enabling it will require putting volatile
everywhere, but when I tried it, it still did not optimize any of the
non-stack method/parameter variables into registers that I could see.

I'm sure some compiler or platform does support it, and I guess it's
possible Microsoft compiler might support it too eventually, but if they
enabled it by default it would break a whole heck of a lot of code. So it
seems that volatile on Intel platforms with the Microsoft compiler by
default really don't require volatile in almost any circumstance.



Or am I missing something?


.

Relevant Pages

  • Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
    ... It doesn't mean that (volatile int*) cast is bad, ... I would agree that fixing the compiler in this case would be a good thing, ... bad register allocation. ... still quite possible to find cases where it did some optimization (in this ...
    (Linux-Kernel)
  • Re: Is the following code MT-Safe?
    ... the assert (which is a fundamental design error: ... and almost always leads to either major synchronization failures ... >Does _bRunning need to be tagged as volatile? ... compiler to cache values, but only during the execution of a function; ...
    (microsoft.public.vc.mfc)
  • Re: Volatile for shared data protected by critical section
    ... I don't think that it optimizes register variable use across function calls. ... seeing 'volatile' used much with globals in the CE code base. ... Does the current compiler implementation not attempt to optimize variables ... You are right that the global data will be shared by multiple threads ...
    (microsoft.public.windowsce.embedded)
  • Re: Volatile + multithreading
    ... The volatile keyword has little use in multithreaded programming. ... > field or global seems to have no impact because it seems the compiler will ... operations as "special" and suppress optimizations around them. ... > majority of the multithreading issues that could have resulted from ...
    (microsoft.public.vc.language)
  • Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
    ... If I could trust atomic_read/atomic_setto cause the compiler ... as you've explained it below) -- neither w.r.t. CPU re-ordering (which ... You are correct about CPU re-ordering (and about the fact that this ... The compiler is prohibited from moving a volatile access across a sequence ...
    (Linux-Kernel)