> 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/