On Tue, Mar 06, 2007 at 12:13:16PM +0100, Bert Wesarg wrote: > Gleb Natapov wrote: > > On Tue, Mar 06, 2007 at 11:24:06AM +0100, Bert Wesarg wrote: > >> Hello, > >> > >> Gleb Natapov wrote: > >>> If it does this after opal_atomic_lock() (which is explicit memory > >>> barrier) then it is broken. > >> Than, gcc 4.1.1 on the amd64 architecture is broken: > > And can you repeat the test please, but make "test" variable to be global > > to tell compiler that it can be actually accessed by more then one > > thread. > > > > ahh, now both produce nearly the same code. > > but who hurts it to declare the variable volatile? > The disadvantage of using volatile is that compiler will produce inefficient code for every access to a variable and not only specific access that you care about, so it is better to do proper memory barrier in places where ordering is important and let compiler optimize all other cases. But what is even more important is that in most cases volatile is not enough. CPU may reorder accesses to memory and volatile doesn't help, so volatile is not a replacement for memory barriers. You can find Linus rants about volatile usage in LKML archives for entertainment reading. Volatile is overused in Open MPI anyway.
> Bert > --- double_check.s 2007-03-06 12:07:12.103478512 +0100 > +++ double_check_volatile.s 2007-03-06 12:06:20.675315485 +0100 > @@ -1,4 +1,4 @@ > - .file "double_check.c" > + .file "double_check_volatile.c" > .text > .p2align 4,,15 > .globl main > @@ -13,8 +13,9 @@ > # first if > > #NO_APP > - decl %eax > + movl test(%rip), %eax > movl $1, %edx > + decl %eax > je .L4 > #APP > # lock > @@ -43,7 +44,8 @@ > # second if > > #NO_APP > - cmpl $1, test(%rip) > + movl test(%rip), %eax > + decl %eax > jne .L8 > #APP > # if unlock > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Gleb.
