[lkml]   [1999]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: spin_unlock optimization(i386)
    On Mon, 29 Nov 1999, Gerard Roudier wrote:

    >(WBUF=write buffer)
    >CPU1 CPU2
    >---- ----
    >STORE A -> WBUF
    > LOAD A <- CACHE
    > STORE B -> WBUF
    >STORE B -> WBUF
    > DRAIN B -> CACHE
    >I donnot want to write concurrently to the same location without
    >synchronisation especially because of the CPU write buffers that may hide
    >STOREs from the cache (or memory) and may hit further LOADs, but you seem
    >to be a lot more courageous than I am. ;-)

    If you write concurrently to the same location you can't expect anything.
    Everything can happen.

    It's just like if you write in parallel to the same file without any
    locking. You don't know what will you find then. You can't rely on the
    timings. You must avoid that by design.

    If in the wait_even interface there is a chance for a write contention it
    means that the read is not yet happened and the write that will unlock the
    path is just happened and finished. So the further write will notice that
    the event just happened. We don't care at all about the result of the
    colliding writes.

    Your example tell you nothing of new. You are doing this:

    (WBUF=write buffer)

    CPU1 CPU2
    ---- ----

    And if you run only a write B, you have no garantee at all if it will be
    executed first on CPU 1 or CPU 2 or what will be the result. So it doesn't
    matter what the WBUF is doing from under you. Even without the WBUF and
    without the cache you would have no garantee because you could be
    interrupt at any time from an irq handler for example and the CPU 2 that
    you expect to execute the store first could execute it later. Also I don't
    assume the cpus runs at the same speed.

    The wait_event interface can break only if some asm instruction gets
    reodered, it doesn't matter if two colliding writes are trashing the
    result. If there is a collision it means the further read will avoid
    blocking in the waiter because if there is collision the unlock on the
    other cpu just happened and _finished_.

    >choose a SMP synchronisation that is no more so and especially not to

    The wait_event interface (after the fixes I did in 2.3.1x) it's obviously
    correct on alpha-smp, so I don't think that removing it is the right way
    to go (and I believe the 2.3.x kernel tree is just correct).


    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.028 / U:15.192 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site