On 5/7/2013 6:25 AM, Andrei Alexandrescu wrote:
> No. A tutorial on memory consistency models would be too long to insert here. I
> don't know of a good online resource, does anyone?

Here's one written by this Andrei Alexandrescu fellow, I hear he knows what he's talking about:

http://erdani.com/publications/DDJ_Jul_Aug_2004_revised.pdf

On 5/7/13 12:30 PM, deadalnix wrote:
> On Tuesday, 7 May 2013 at 16:14:50 UTC, Steven Schveighoffer wrote:
>> Not really. Whether it is entered or not is dictated by the vtable.
>> Even classic double-check locking doesn't need an acquire outside the
>> lock. Even if your CPU's view of the variable is outdated, the check
>> after the memory barrier inside the lock only occurs once. After that,
>> steady state is achieved. All subsequent reads need no memory
>> barriers, because the singleton object will never change after that.
>>
>> The only thing we need to guard against is non-atomic writes, and out
>> of order writes of the static variable (fixed with a memory barrier).
>> Instruction ordering OUTSIDE the lock is irrelevant, because if we
>> don't get the "steady state" value (not null), then we go into the
>> lock to perform the careful initialization with barriers.
>>
>> I think aligned native word writes are atomic, so we don't have to
>> worry about that.
>>
>
> That is incorrect as the thread not going into the lock can see a
> partially initialized object.

Correct.

Andrei

On 5/7/13 12:46 PM, Steven Schveighoffer wrote:
> On Tue, 07 May 2013 12:30:05 -0400, deadalnix <deadalnix@gmail.com> wrote:
>
>> On Tuesday, 7 May 2013 at 16:14:50 UTC, Steven Schveighoffer wrote:
>>> Not really. Whether it is entered or not is dictated by the vtable.
>>> Even classic double-check locking doesn't need an acquire outside the
>>> lock. Even if your CPU's view of the variable is outdated, the check
>>> after the memory barrier inside the lock only occurs once. After
>>> that, steady state is achieved. All subsequent reads need no memory
>>> barriers, because the singleton object will never change after that.
>>>
>>> The only thing we need to guard against is non-atomic writes, and out
>>> of order writes of the static variable (fixed with a memory barrier).
>>> Instruction ordering OUTSIDE the lock is irrelevant, because if we
>>> don't get the "steady state" value (not null), then we go into the
>>> lock to perform the careful initialization with barriers.
>>>
>>> I think aligned native word writes are atomic, so we don't have to
>>> worry about that.
>>>
>>
>> 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.

Andrei

On 5/7/13 1:31 PM, Walter Bright wrote:
> On 5/7/2013 6:25 AM, Andrei Alexandrescu wrote:
>> No. A tutorial on memory consistency models would be too long to
>> insert here. I
>> don't know of a good online resource, does anyone?
>
> Here's one written by this Andrei Alexandrescu fellow, I hear he knows
> what he's talking about:
>
> http://erdani.com/publications/DDJ_Jul_Aug_2004_revised.pdf

That doesn't get into memory models.

Andrei

07-May-2013 17:25, Andrei Alexandrescu пишет:
> On 5/7/13 2:50 AM, Mehrdad wrote:
>> On Monday, 6 May 2013 at 18:46:56 UTC, Andrei Alexandrescu wrote:
>>> Any concurrent operation (in this case read from one thread and write
>>> from another) requires a handshake between threads, most often in the
>>> form of an release write coupled with an acquire read. Whenever the
>>> handshake is absent but concurrent operations on shared memory do
>>> occur, the code is broken. The beauty of the TLS-based pattern is that
>>> in the steady state there's no need for a shared read and handshake.
>>>
>>> Andrei
>>
>>
>>
>> Hmm, are you referring to the same lack of a barrier that the others are
>> also referring to?
>>
>>
>> As far as I can see, there shouldn't be a need for any other handshake
>> in this example.
>>
>> As long as the object is fully initialized before _static is written to
>> (easy enough with just a memory barrier), there is no penalty for
>> subsequent reads whatsoever.
>>
>> Right?
>
> No. A tutorial on memory consistency models would be too long to insert
> here. I don't know of a good online resource, does anyone?
>

Sutter's Mill is a good starting point even though it's C++ biased.

Two recent insightful talks on C++11 memory model with down and dirty details:

http://herbsutter.com/2013/02/11/atomic-weapons-the-c-memory-model-and-modern-hardware/


-- 
Dmitry Olshansky

-- 
Dmitry Olshansky

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@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.


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).


-- 
Dmitry Olshansky

> No. A tutorial on memory consistency models would be too long to insert here. I don't know of a good online resource, does anyone?
>
> Andrei

This was very helpful for me - focuses much more on the memory model itself than the c++11 part.

http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb-Sutter-atomic-Weapons-1-of-2

On Tuesday, 7 May 2013 at 20:17:43 UTC, QAston wrote:
>> No. A tutorial on memory consistency models would be too long to insert here. I don't know of a good online resource, does anyone?
>>
>> Andrei
>
> This was very helpful for me - focuses much more on the memory model itself than the c++11 part.
>
> http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb-Sutter-atomic-Weapons-1-of-2

Nah, look @ Dmitry's post, he was first to post that :P

On Tuesday, 7 May 2013 at 13:25:37 UTC, Andrei Alexandrescu wrote:
> A tutorial on memory consistency models would be too long to insert here. I don't know of a good online resource, does anyone?

The best explanation I've found of memory models is this paper:

http://dl.acm.org/citation.cfm?id=325102

Which can be had for free (albeit in terrible print quality) here:

http://eecs.vanderbilt.edu/courses/eece343/papers/p15-gharachorloo.pdf

Kourosh Gharachorloo actually has a number of really good papers about this stuff.  Here's another, if you're interested in the details of how things work:

http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-9.pdf

On Tuesday, 7 May 2013 at 19:49:30 UTC, Andrei Alexandrescu wrote:
> 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.
>
> Andrei



Andrew, I still don't understand:

The writer is ensuring that writes to memory are happening _after_ the object is initialized and _before_ the reference to the old object is modified, via a memory barrier.


Unless you're claiming that a memory barrier _doesn't_ do what it's supposed to (i.e., the memory module is executing writes out-of-order even though the processor is issuing them in the correct order), there is no way for _anyone_ to see a partially initialized object anywhere...