[lkml]   [1999]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: spin_unlock optimization(i386)
On Thu, 25 Nov 1999, Oliver Xymoron wrote:

>[..] I don't see anything that
>suggests a write on CPU 1 throws out a speculative read result on CPU 2.

In one of Erich's email you'll see exactly that.

I quote him:

On Wed, 24 Nov 1999, Erich Boleyn wrote:
>Date: Wed, 24 Nov 1999 15:48:00 -0800
>From: Erich Boleyn <>
>To: Andrea Arcangeli <>
>Cc: Manfred Spraul <>,
> Erich Boleyn <>,,
>Subject: Re: spin_unlock optimization(i386)
>For the following case:
> spin_lock(X);
>...*regardless* of speculation, the value gotten by "READ Y" will be
>consistent with anything observed by the processor in "spin_lock", else
>it violates the program order, and normal programs would not work very
>well. It's perfectly OK to hoist "READ Y" above "spin_lock"
>speculatively... for example, consider the following sequence:
> -- processor A: "READ Y" is speculatively executed, now waiting
> to be committed to state.
> -- processor A: "spin_lock(X)" is spinning in it's loop...
> -- processor B: executes "STORE Y", then executes "spin_unlock(X)"
>Now NOTE:
> -- processor A: to observe X for the "spin_lock(X)" to succeed, it
> *must* observe "STORE Y" first.
> -- processor A: observing "STORE Y" requires it to throw away the
> speculative "READ Y" with the possibly wrong value. It may
> attempt to reexecute "READ Y" at this time with the correct
> value.
> -- processor A: now "spin_lock(X)" can see the new value of X and
> finish.


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

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