On Wed, May 09, 2012 at 09:24:41AM -0700, H. Peter Anvin wrote: > On 05/09/2012 08:47 AM, Michael S. Tsirkin wrote: > > > > By the way, clear_bit on x86 does not seem to contain > > an optimization barrier - is my reading correct? > > Lock prefix does not affect the compiler, right? > > Yes, as it clearly states in the comment: > > * clear_bit() is atomic and may not be reordered. However, it does > * not contain a memory barrier, so if it is used for locking purposes, > * you should call smp_mb__before_clear_bit() and/or > smp_mb__after_clear_bit() > * in order to ensure changes are visible on other processors. > > There is clear_bit_unlock() which has the barrier semantics. > > -hpa Well it talks about a memory barrier, not an optimization barrier. If compiler reorders code, changes will appear in the wrong order on the current processor, not just on other processors, no? Sorry if I'm confused about this point, this is what Documentation/atomic_ops.txt made me believe: <quote> For example consider the following code: while (a > 0) do_something(); If the compiler can prove that do_something() does not store to the variable a, then the compiler is within its rights transforming this to the following: tmp = a; if (a > 0) for (;;) do_something(); </quote> > > -- > H. Peter Anvin, Intel Open Source Technology Center > I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
