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 -- 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-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
