On Tuesday, 7 May 2013 at 22:12:17 UTC, Steven Schveighoffer
wrote:
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?
Short answer : because read can be done out of order and/or from
cached values. The reader must do its part of the job as well.
You ay want to read this serie of articles, they are very
interesting.
http://preshing.com/20120913/acquire-and-release-semantics
