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/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:15 EST