[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);
    > READ Y;
    >...*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.023 / U:89.116 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site