José Fonseca pisze: > On Tue, 2009-04-21 at 02:52 -0700, Michał Król wrote: > >> Jose Fonseca pisze: >> >>> Module: Mesa >>> Branch: master >>> Commit: 86ed894e47bae10d158f2b4a02065daa9dbe5194 >>> URL: >>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=86ed894e47bae10d158f2b4a02065daa9dbe5194 >>> >>> Author: José Fonseca <[email protected]> >>> Date: Fri Apr 17 18:40:46 2009 +0100 >>> >>> pipe: Get the p_atomic_dec_zero logic right this time. >>> >>> --- >>> >>> src/gallium/include/pipe/p_atomic.h | 5 ++--- >>> 1 files changed, 2 insertions(+), 3 deletions(-) >>> >>> diff --git a/src/gallium/include/pipe/p_atomic.h >>> b/src/gallium/include/pipe/p_atomic.h >>> index ed5f665..0c3fbae 100644 >>> --- a/src/gallium/include/pipe/p_atomic.h >>> +++ b/src/gallium/include/pipe/p_atomic.h >>> @@ -225,7 +225,7 @@ p_atomic_cmpxchg(struct pipe_atomic *v, int32_t old, >>> int32_t _new) >>> >>> struct pipe_atomic >>> { >>> - long count; >>> + volatile long count; >>> }; >>> >>> >> Jose, >> >> Could you explain why the `volatile' keyword above is necessary? We are >> using InterlockedDecrement/Increment() functions to operate on it, and I >> believe any function call should be a sufficient memory barrier. >> > > Michal, > > I added the volatile keyword because many of the InterlockedIncrement > examples I found in internet use the volatile keyword, and the > InterlockedIncrement/Decrement function themselves have volatile pointer > as their arguments. > > See http://msdn.microsoft.com/en-us/library/f24ya7ct(VS.71).aspx for an > example. But you can also find examples that don't. > > In my interpretation volatile makes sense -- the variable can change at > any time, and we don't want the compiler to keep a local/outdated copy > in a register. > > This is a common misconception. When I was young I thought the same, but now I am a convertee.
The `volatile' qualifier doesn't mean that the variable is going to be put in some special memory location that forces the CPU to behave in a desired way (this is different than, say, `align' qualifier that makes the compiler put the variable at e.g. word boundaries). It's all about how the compiler is going to handle variables declared that way. InterlockedXXX() functions can be translated into intrinsics which means there could be no memory barrier after optimistation. Note however that the `volatile' keyword in formal argument declaration guarantees the actual argument is going to be treated as such event if it was not declared volatile in the first place. http://www.tech-archive.net/Archive/VC/microsoft.public.vc.mfc/2005-01/0702.html ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
