Messages in this thread | | | Date | Mon, 29 Nov 1999 01:22:54 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: 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/
| |