Re: Volatile for shared data protected by critical section

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

Interesting, I hadn't really thought much about this. Other than variables
used for hard spin loops and register accesses, I don't recall seeing
'volatile' used much with globals in the CE code base.

Does the current compiler implementation not attempt to optimize variables
across function calls, or are we just getting lucky because the call to
EnterCriticalSection happens to consume all the registers that could be used
for optimization?

--
Dean Ramsier - eMVP
BSQUARE Corporation


"Paul G. Tobey [eMVP]" <paultobey _at_ earthlink _dot_ net> wrote in message
news:9395D70D-BEDE-466C-BC91-AFF560B83C2E@xxxxxxxxxxxxxxxx
It should be declared volatile, regardless of whether you've properly
protected it or not. Volatile is a hint to the compiler that it should
not
assume that some previously cached (usually in a processor register),
value
will still be valid just because the compiler doesn't see any code in the
current block that will change the value. While it's doubtful that this
would ever cause you a problem if you are enclosing all code that accesses
the variable in a critical section, future enhancements to global
optimization in the compiler might note that you are not changing that
variable value in the code block and decide that it should be cached and
only
the cached value used.

Paul T.

"shiju" wrote:

Thanks Bruce for your response.
You are right that the global data will be shared by multiple threads
but these data are protected within a critical section . But not sure
whether the global data that is protected within a critical section
needs to be declared as volatile. In some OS like linux, it says that
don't use volatile if the global data is already protected with
spin_locks etc.
(http://www.mjmwired.net/kernel/Documentation/volatile-considered-harmful.txt).
I don't see any such info for wince or windows.

Thanks,
Shiju
Bruce Eitman [eMVP] wrote:
I am not sure that I followed you completely. But, if the global data
will
be shared by multiple threads then you should use volatile. This
ensures
that the compiler knows that the data could be modified by another
thread.
It would also tell the compiler that writes must be done before the
function
call since the compiler has no idea what is being done in the critical
section functions.




.

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: 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: Should this static variable be volatile?
    ... SetRetValto change the default RetValue: ... The compiler must consider that 'RetVal' becomes changed ... You need 'volatile' in three (as far as I am aware of at the ... such a register can have side-effects the compiler can't ...
    (comp.lang.c)
  • Re: What does this code do?
    ... declared "volatile"; does it actually cause the compiler to treat the ... causes the compiler to store them in memory instead of in a register ... As long as the program behaves "as if" &foo ...
    (comp.lang.c.moderated)
  • Re: Volatile for shared data protected by critical section
    ... be shared by multiple threads then you should use volatile. ... It would also tell the compiler that writes must be done before the function ... We have a shared global data that needs to be protected by critical ...
    (microsoft.public.windowsce.embedded)