On Tue, 07 May 2013 16:02:08 -0400, Dmitry Olshansky
<[email protected]> wrote:
07-May-2013 23:49, Andrei Alexandrescu пишет:
On 5/7/13 12:46 PM, Steven Schveighoffer wrote:
On Tue, 07 May 2013 12:30:05 -0400, deadalnix <[email protected]>
wrote:
[snip]
That is incorrect as the thread not going into the lock can see a
partially initialized object.
The memory barrier prevents that. You don't store the variable until
the
object is initialized. That is the whole point.
A memory barrier is not a one-way thing, i.e. not only the writer must
do it. Any operation on shared memory is a handshake between the writer
and the reader. If the reader doesn't do its bit, it can see the writes
out of order no matter what the writer does.
Exactly.
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.
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?
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?
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?
-Steve
