Low-Lock Singletons In D

[Steven Schveighoffer]

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?

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