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

>(WBUF=write buffer)
>
>CPU1 CPU2
>---- ----
>STORE A -> WBUF
>DRAIN A -> CACHE
> LOAD A <- CACHE
> STORE B -> WBUF
>STORE B -> WBUF
>DRAIN B -> CACHE
> 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
---- ----
STORE B
STORE B

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).

Andrea


-
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:1.743 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site