Re: [PATCH] bitops: add _local bitops

["Michael S. Tsirkin" <mst@redhat.com>]

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.