[lkml]   [2004]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] x86 bitops.h commentary on instruction reordering
Marcelo Tosatti wrote:
>>>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 know basically, how spinlocks work to provide ordering, my question
was about the cache coherency. Thanks for the link to the book, I will
try to find it.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [W:0.048 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site