lkml.org 
[lkml]   [1999]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: spin_unlock optimization(i386)
From
Date
"Stefan Monnier" <monnier+lists/linux/kernel/news/@tequila.cs.yale.edu> wrote:
> >>>>> "Andrea" == Andrea Arcangeli <andrea@suse.de> writes:
> > Because the write buffer as documented is not allowed to show changes to
> > the other cpus not in processor order. It can only delay the writes
> > undefinitely but that make no difference at all for SMP.
>
> Of course it makes a difference:
>
> A = 1 B = 0
> read B read A
>
> You might very well get `read A=0' and `read B=1' even though this
> does not correspond to any UP interleaving of the two threads.

That wasn't my understanding.

read B read A (<- speculative)
A = 1
B = 0
read A (*)

Here read B=?, but read A=1. A is read speculatively, but because
write B=0 is seen *after* the write A=1, the speculative read on A is
thrown away. The speculative read for B is accepted because there
were no writes to B before the write to A.

Just flip the diagram to get the case for B.

It is my understanding that a read for A that follows a write to B on
one processor can move *before* that write, but the read result on A
isn't retired until after the write to B occurs (in processor order).

The processor sees all writes before it's own that have occurred after
the read (so it sees A=1), and if any of them touch A, it will
invalidated the read on A, *before* its result is retired. The read
is redone, and it gets the correct value for A.

Drago

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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