Messages in this thread | | | Date | Fri, 26 Nov 1999 20:00:55 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: spin_unlock optimization(i386) |
| |
On Fri, 26 Nov 1999, Manfred Spraul wrote:
> I looked at your program [the version from this morning, 11:34], and > this test checks for write ordering, not for the causality problem:
well, causality means 'can another CPU observe something out of order'. It doesnt matter _why_ the causality violation happens: wether it's due to write reordering (which cannot happen), or read reordering. A Processor Ordered memory model has both reads and writes ordered properly for all observers (it can still do noncommitted internal reordering), in a multiprocessor system.
> if you want to trigger the bug, then you must _both_ read and write data > from one cpu. If one cpu writes data, and one cpu reads data, then > you'll never trigger the problem.
yep, thats another type of causality violation, will try to generate a testcase. [i think i have one, i'm checking it now]
> The problem has _nothing_ to do with the cache lines,..: the cache > protocol enforces the coherency, the problem lies _before_ the data > enters the cache.
yes, but nevertheless certain types of internal CPU structures are cacheline sized, and if we want to see a higher parallelizm and a higher chance of causality violation then i thought it's better if data is on different cachelines. I agree that it shouldnt matter though from the correctness point of view, both cases have to work and both might fail, depending on the implemented memory model.
-- mingo
- 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/
| |