On Monday, 6 May 2013 at 09:35:59 UTC, Dmitry Olshansky wrote:
> You have to read a field to know what to do next, and the other processor may as well write to it.


That never happens, though. _static is only written to inside a lock, and the check is inside a lock, hence the other processor can't be writing to it when it's being read...


Maybe I misunderstood what you're saying?

On Monday, 6 May 2013 at 10:06:50 UTC, Mehrdad wrote:
> On Monday, 6 May 2013 at 09:35:59 UTC, Dmitry Olshansky wrote:
>> You have to read a field to know what to do next, and the other processor may as well write to it.
>
>
> That never happens, though. _static is only written to inside a lock, and the check is inside a lock, hence the other processor can't be writing to it when it's being read...
>
>
> Maybe I misunderstood what you're saying?

ON x86 you rarely see this kind of thing as the memory model is strong. You can see some weird thing in rare cases, but as soon as you leave x86 world, it isn't even worth trying.

On Monday, 6 May 2013 at 10:12:53 UTC, deadalnix wrote:
> On Monday, 6 May 2013 at 10:06:50 UTC, Mehrdad wrote:
>> On Monday, 6 May 2013 at 09:35:59 UTC, Dmitry Olshansky wrote:
>>> You have to read a field to know what to do next, and the other processor may as well write to it.
>>
>>
>> That never happens, though. _static is only written to inside a lock, and the check is inside a lock, hence the other processor can't be writing to it when it's being read...
>>
>>
>> Maybe I misunderstood what you're saying?
>
> ON x86 you rarely see this kind of thing as the memory model is strong. You can see some weird thing in rare cases, but as soon as you leave x86 world, it isn't even worth trying.


Ah yeah, this entire thing was geared toward x86.

On a second thought, maybe it probably doesn't improve anything compared to the double-checked lock, since the branch prediction for 'if' is most likely faster than the branch prediction for a virtual call anyway. It was worth trying I guess...

06-May-2013 14:06, Mehrdad пишет:
> On Monday, 6 May 2013 at 09:35:59 UTC, Dmitry Olshansky wrote:
>> You have to read a field to know what to do next, and the other
>> processor may as well write to it.
>
>
> That never happens, though. _static is only written to inside a lock,

Yes, but the 1st processor may read _static exactly when the 2nd is inside the lock and writing to that field. Then chances are it will read whatever partial state there is written.

> and the check is inside a lock, hence the other processor can't be
> writing to it when it's being read...

Surely it can. 1st processor takes the lock and write while the second one reads static_ to call Get.

>
>
> Maybe I misunderstood what you're saying?
I bet you just mystified the pattern a bit by relying on indirect call.

In pseudo-code what you do is this:


read static_ // 1st processor may be reading here
if static_ is NullValue //that is indirect call
	lock(static_){
		check again
		write static_ //while 2nd one writes here
	}
else
	call static_ -~~-> get

I claim that 'read  static_' better be "protected" against that 'write static_' inside the lock.

One way is to ensure write is atomic w.r.t. that particular read operation e.g. by hardware acquire-release, or via both reads/writes being atomic.
On x86 word-sized reads/writes are atomic anyway (iff aligned apparently).

The neat stuff about that TLS pattern was that you need not to rely on hardware specific support.

-- 
Dmitry Olshansky

On Monday, 6 May 2013 at 02:35:33 UTC, dsimcha wrote:
> On the advice of Walter and Andrei, I've written a blog article about the low-lock Singleton pattern in D.  This is a previously obscure pattern that uses thread-local storage to make Singletons both thread-safe and efficient and was independently invented by at least me and Alexander Terekhov, an IBM researcher.  However, D's first-class treatment of thread-local storage means the time has come to move it out of obscurity and possibly make it the standard way to do Singletons.
>
> Article:
> http://davesdprogramming.wordpress.com/2013/05/06/low-lock-singletons/
>
> Reddit:
> http://www.reddit.com/r/programming/comments/1droaa/lowlock_singletons_in_d_the_singleton_pattern/

FWIW, I played with a generalized form of this pattern long ago, something like (typing from memory):

template sharedGlobal(alias ctor, alias lock = globalLock)
{
     @property sharedGlobal()
     {
         alias ReturnType!ctor T;
         __gshared static Nullable!T t;
         static bool instantiated;

         if (!instantiated)
         {
             synchronized(lock)
             {
                 if (t is null)
                     t = ctor();
             }
     }

     return cast(T)t;
}

alias sharedGlobal!({ return new Blah(); }) blah;

It should have been part of QtD but that has never happened.

On 5/6/13 5:06 AM, Mehrdad wrote:
> On Monday, 6 May 2013 at 02:35:33 UTC, dsimcha wrote:
>> that uses thread-local storage
>> On DMD the overhead of TLS vs. unsafe is noticeable but small. In both
>> cases it pales in comparison to the overhead of synchronizing on every
>> call to get().
>
>
> Hmm...
>
> So I just invented another method right now in like 10 minutes, which
> can completely avoid TLS altogether, and which I think might end up
> being faster.

It's well known. Needs a memory barrier on each access, so it's slower.

Andrei

On 5/6/2013 6:14 AM, Max Samukha wrote:
> FWIW, I played with a generalized form of this pattern long ago, something like
> (typing from memory):

And, that's the classic double checked locking bug!

On Mon, 06 May 2013 13:58:19 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 5/6/2013 6:14 AM, Max Samukha wrote:
>> FWIW, I played with a generalized form of this pattern long ago, something like
>> (typing from memory):
>
> And, that's the classic double checked locking bug!
>

I think that's exactly what David had in his slide (well, except for an obvious typo).

He's only checking t once, and protecting the lock/check with a TLS boolean.  Although the set of the boolean is missing (probably a memory error, since he typed it from memory :)

-Steve

On Monday, 6 May 2013 at 11:21:37 UTC, Dmitry Olshansky wrote:
> Yes, but the 1st processor may read _static exactly when the 2nd is inside the lock and writing to that field. Then chances are it will read whatever partial state there is written.
> Surely it can. 1st processor takes the lock and write while the second one reads static_ to call Get.


It's a single pointer, there is no partial state -- it's either written or it isn't.


> One way is to ensure write is atomic w.r.t. that particular read operation


Are't pointer writes always atomic?


> The neat stuff about that TLS pattern was that you need not to rely on hardware specific support.

Ah okay I see, didn't realize that.

On Monday, 6 May 2013 at 13:33:54 UTC, Andrei Alexandrescu wrote:
> It's well known. Needs a memory barrier on each access, so it's slower.


Hmm, are you saying I'm missing a memory barrier I should have written, or are you saying I already have a memory barrier which I'm not seeing?


The only memory barrier I have is during initialization, and after that only read operations occur.