Low-Lock Singletons In D

[Andrei Alexandrescu]

On 5/7/13 6:12 PM, Steven Schveighoffer wrote:
> 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.

Yes. (One detail is there are several kinds of barriers, such as acquire 
and release.)

> 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?

There are several actors involved: two processors, each with its own 
cache, and the main memory. There are several cache coherency protocols, 
which reflect in different programming models.

> 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?

Not at all. A memory barrier dictates operation ordering. It doesn't do 
interlocking. One of Herb's slides shows very nicely how memory 
operations can't be moved ahead of an acquire and past a release.

>> 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?

No.


Andrei