Re: [PATCH] x86 bitops.h commentary on instruction reordering

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

On Llu, 2004-08-09 at 21:12, Vladislav Bolkhovitin wrote:
> Well, Marcelo, sorry if I'm getting too annoying, but we had a race with 
> cache coherency during SCST (SCSI target mid-level) development. We 
> discovered that on P4 Xeon after atomic_set() there is very small 
> window, when atomic_read() on another CPUs returns the old value. We had 
> to rewrite the code without using atomic_set(). Isn't it cache coherency 
> issue?

atomic_set/atomic_read are _atomic_ operations. Nothing is said about
ordering. You get old or new but not half and half. Two atomic_inc's
will both occur and so on.

If you want ordering you need locks otherwise there is nothing defining
the time order of both processors.

How can you even measure such a window without locking to know what the
state of the processors is ?

> And, BTW, returning to the original topic, would it be better to make 
> set_bit() and friends guarantee not to be reordered on all 
> architectures, instead of just add the comment. Otherwise, what is the 

x86 and some other platforms have certain ordering guarantees. set_bit
doesn't guarantee them but it happens to unavoidably work for most
(ab)uses.

> right thing? In some places in SCST we heavy rely on non-ordering 
> guarantees.

Then you will get burned on most hardware.