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