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

[Alan Cox]

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/