On Thu, 20 Jul 2000 23:08:12 -0700,
"Linda Walsh" <law@sgi.com> wrote:
>oxymoron 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.
>
> You say we are 'assuming' writes show up in the order performed, that
>implies it may not be true? 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?
Linux requires strong write ordering[*]. That is, write A followed by
write B will appear in memory in the order of A then B. So if any
write on processor 1 is committed to memory then all preceding writes
by processor 1 must already have been committed to memory.
If the memory area is configured as writeback then writes can be
buffered until the cache line is flushed so yes, a write may not appear
in memory immediately. However any hardware cache coherent scheme will
force a flush for dirty cache lines if another processor wants that
line. That is, buffered writes will be flushed if the data is read on
another processor, again this assumes the hardware supports cache
coherence.
A speculative read for a cache line which is dirtied after the
speculation but before the "real" read can be handled in two ways.
Either the old data that was read is used or the data is discarded and
the latest value is read. For the type of access Linda wants, either
result is acceptable. Without a lock you read either the old value or
the new value, it is entirely timing dependent. Speculative reads make
no difference, they just appear as timing differences.
Even with a lock, you get exactly the same result. The reader either
gets the lock before the writer and reads the old value or it gets the
lock after the writer and reads the new value. The writers need to
lock against each other to avoid concurrent updates but the readers do
not need a lock just to read an integer.
[*] Except for certain areas of memory such as video memory where the
specific write order does not matter.
-
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