lkml.org 
[lkml]   [1999]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.094 / U:0.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site