Low-Lock Singletons In D
deadalnix
deadalnix at gmail.com
Tue May 7 22:31:15 PDT 2013
On Tuesday, 7 May 2013 at 22:12:17 UTC, Steven Schveighoffer
wrote:
> On Tue, 07 May 2013 16:02:08 -0400, Dmitry Olshansky
> <dmitry.olsh at gmail.com> 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
>>>> <deadalnix at gmail.com>
>>>> 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
More information about the Digitalmars-d
mailing list