On 5/7/13 6:12 PM, Steven Schveighoffer wrote:
So the memory barrier ensures that neither the compiler nor the
processor can re-order the stores to memory.
But you are saying that the *reader* must also put in a memory barrier,
otherwise it might see the stores out of order.
Yes. (One detail is there are several kinds of barriers, such as acquire
and release.)
It does not make sense to me, how does the reader see a half-initialized
object, when the only way it sees anything is when it's stored to main
memory *and* the stores are done in order?
There are several actors involved: two processors, each with its own
cache, and the main memory. There are several cache coherency protocols,
which reflect in different programming models.
So that must not be what it is doing. What it must be doing is storing
out of order, BUT placing a prevention mechanism from reading the memory
until the "release" is done? Kind of like a minuscule mutex lock. So
while it is out-of-order writing the object data, it holds a lock on the
reference pointer to that data, so anyone using acquire cannot read it yet?
That actually makes sense to me. Is that the case?
Not at all. A memory barrier dictates operation ordering. It doesn't do
interlocking. One of Herb's slides shows very nicely how memory
operations can't be moved ahead of an acquire and past a release.
Returning to the confusing point.
On x86 things are actually muddied by stronger then required hardware
guarantees. And only because of this there no need for explicit read
barrier (nor x86 have one) in this case. Still the read operation has
to be marked specifically (volatile, asm block, whatever) to ensure
the _compiler_ does the right thing (no reordering of across it).
I would think the model Mehrdad used would be sufficient to prevent
caching of the data, since it is a virtual, no?
No.
Andrei
