Messages in this thread | | | Date | Fri, 21 Jul 2000 01:37:08 -0500 (CDT) | From | Oliver Xymoron <> | Subject | RE: Cache coherency... and locking |
| |
On Thu, 20 Jul 2000, Linda Walsh wrote:
> > > To answer Linda's original question, whether it's necessary to use a lock > > is very much dependent on the operation you're performing. It's safe to > > assume there's an arbitrarily long delay before your write appears to > > another processor, but we're also currently assuming that all writes show > > up in the order they were performed. > ---
> Arbitrarily long...no upward bound? A second, minute, hour, > day? Something doesn't seem right about that.
That's the model, yes. I'm not saying it ever happens in practice, but things like halts, f00f bugs, software emulation, etc., might in theory come into play with a given processor's cache coherency scheme.
> You say we are 'assuming' writes show up in the order performed, > that implies it may not be true?
True for all the processors we're currently working with. Linus talks about assuming a 'sane architecture' as the common core and making ports minimal variations from that. Currently write ordering is one of those things considered sane.
> It seems the speculative read cache would only stay around for some > fixed, finite, and small time -- unless the processor is halted. I > can see getting the wrong value for the variable on 1 read, but after > performing a system call another read shouldn't still fetch a stale > value. Could it?
In theory, yes. Not today probably, but on faster machines where the number of cycles to perform a syscall compares a little more favorably to the inter-processor latency..
And it'll definitely be an issue on NUMA machines.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- 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/
| |