On Wed, 2009-04-22 at 01:09 -0700, Michał Król wrote: > 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.
I know volatile doesn't force the CPU to behave in any special way. That's why I said "compiler" above, and not "CPU". > 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 Without volatile keyword, nothing prevents the compiler of translating while(p_atomic_read(v)) { // some work } into eax = v->count; if(eax) { for( ;; ) { // infinite loop !! // some work } } ie. factoring successive reads of p_atomic_read into a single read, since p_atomic_read is not an intrinsic, but defined as #define p_atomic_read(_v) ((_v)->count) Jose ------------------------------------------------------------------------------ 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
