Why do you continue to seem to ignore the CPU write buffers, or just seem
to say they should not make differences, and fall into complex
explanations? Manfred's example was broken because of you both ignoring
the CPU write buffers, in my opinion. I may be wrong for that one, but let
me tell you that as long as you will ignore the CPU write buffers you will
stay in confusion in my opinion.
There are similar things in PCI used for posted writes. Will you beleive
me if I tell you that as seen from my planet numerous PCI device drivers
are broken because of ignoring (or bad understanding) these buffers and
just work in a cross-fingered way due to bus activity, chipset flushing
uselessly these buffers on interrupt and only a short window allowing bad
things to happen. On that one, I am sure I am not wrong. ;-)
Gérard.
Joke: I deal with kind of Asymetric MP since years without locking
mechanism (PCI). If it happens this to get too complex for my brain
that will get older, I may elect to switch so simpler things as SMP.
:-) :o) :) :) :) :) :) :) :)
On Mon, 29 Nov 1999, Andrea Arcangeli wrote:
> 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/