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

[Marcelo Tosatti]

On Mon, Aug 09, 2004 at 07:14:48PM +0400, Vladislav Bolkhovitin wrote:
> Marcelo Tosatti wrote:
> >>>Yes correct. *mb() usually imply barrier(). 
> >>>
> >>>About the flush, each architecture defines its own instruction for doing 
> >>>so,
> >>>PowerPC has  "sync" and "isync" instructions (to flush the whole cache 
> >>>and instruction cache respectively), MIPS has "sync" and so on..
> >>
> >>So, there is no platform independent way for doing that in the kernel?
> >
> >
> >Not really. x86 doesnt have such an instruction.
> 
> But how then spin_lock() works? It guarantees memory sync between CPUs, 
> doesn't it? Otherwise how can it prevent possible races with concurrent 
> data modifications?

It makes use of the "lock" instruction to lock the bus before the "dec" instruction:
                                                                                                                                                                                   
#define spin_lock_string \
        "\n1:\t" \
        "lock ; decb %0\n\t" \
        "js 2f\n" \

That way it prevent races wrt other CPUs. atomic accesses which need to modify 
(atomic_inc, atomic_dec, etc) data also use the "lock" to prevent other CPUs 
from reading the data. 

grep for "lock" in include/asm-i386/.

As hpa said, most x86 instructions (except SSE-related ones) are
strictly ordered (except the cases Alan pointed, which were not known 
to me).

Thats why there is no "sync"-like instruction on x86 (again, except SSE-related 
ones).

This is just a simple and short explanation of how this works. It gets more complex
you think about cache coherency between processors, etc. For more details 
the best book probably is "UNIX Systems for Modern Architectures. 
Symmetric Multiprocessing and Caching for Kernel Programming" - Curt Schimmel (which 
has been suggested here over and over).

I hope that helps.

-
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/