José Fonseca pisze: > 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 > > OK, that makes sense, sorry about the fuss. I was thinking about it in the context of _InterlockedXXX() usage only.
------------------------------------------------------------------------------ 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
