I was looking through Jonathan Davis's pull request to remove static
constructors from std.datetime, and I realized that I don't know
whether Double Checked Locking is legal under D's memory model, and
what the requirements for it to work would be.
(if you're not familiar with the term, check out
http://en.wikipedia.org/wiki/Double-checked_locking - it's a useful
but problematic programming pattern that can cause subtle concurrency
bugs)
It seems like it should be legal as long as the variable tested and
initialized is flagged as shared so that the compiler enforces proper
fences, but is this actually true?

On 2011-12-17 23:10:19 +0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> On 12/17/11 5:03 PM, Jonathan M Davis wrote:
>> Well, you learn something new every day I guess. I'd never even heard of
>> double-checked locking before this. I came up with it on my own in an attempt
>> to reduce how much the mutex was used. Is the problem with it that the write
>> isn't actually atomic? Wikipedia makes it sound like the problem might be that
>> the object might be partially initialized but not fully initialized, which I
>> wouldn't have thought possible, since I would have thought that the object
>> would be fully initialized and _then_ the reference would be assigned to it.
>> And it's my understanding that a pointer assignment like that would be atomic.
>> Or is there more going on than that, making it so that the assignment itself
>> really isn't atomic?
> 
> There so much going on about double-checked locking, it's not even funny. Atomic assignments have the least to do with it. Check this out: http://goo.gl/f0VQG

Shouldn't a properly implemented double-checked locking pattern be part of the standard library? This way people will have a better chance of not screwing up. I think the pattern is common enough to warrant it.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On Saturday, December 17, 2011 22:16:38 Michel Fortin wrote:
> On 2011-12-17 23:10:19 +0000, Andrei Alexandrescu
> 
> <SeeWebsiteForEmail@erdani.org> said:
> > On 12/17/11 5:03 PM, Jonathan M Davis wrote:
> >> Well, you learn something new every day I guess. I'd never even heard
> >> of
> >> double-checked locking before this. I came up with it on my own in an
> >> attempt to reduce how much the mutex was used. Is the problem with it
> >> that the write isn't actually atomic? Wikipedia makes it sound like
> >> the problem might be that the object might be partially initialized
> >> but not fully initialized, which I wouldn't have thought possible,
> >> since I would have thought that the object would be fully initialized
> >> and _then_ the reference would be assigned to it. And it's my
> >> understanding that a pointer assignment like that would be atomic. Or
> >> is there more going on than that, making it so that the assignment
> >> itself really isn't atomic?
> > 
> > There so much going on about double-checked locking, it's not even funny. Atomic assignments have the least to do with it. Check this out: http://goo.gl/f0VQG
> 
> Shouldn't a properly implemented double-checked locking pattern be part of the standard library? This way people will have a better chance of not screwing up. I think the pattern is common enough to warrant it.

Well, from the sounds of it, the basic double-checked locking pattern would work just fine with a shared variable if shared were fully implemented, but since it's not, it doesn't work right now. So, I don't know that we need to do anything other than finish implementing shared.

- Jonathan M Davis

On 2011-12-18 04:35:08 +0000, Jonathan M Davis <jmdavisProg@gmx.com> said:

> On Saturday, December 17, 2011 22:16:38 Michel Fortin wrote:
>> Shouldn't a properly implemented double-checked locking pattern be part
>> of the standard library? This way people will have a better chance of
>> not screwing up. I think the pattern is common enough to warrant it.
> 
> Well, from the sounds of it, the basic double-checked locking pattern would
> work just fine with a shared variable if shared were fully implemented, but
> since it's not, it doesn't work right now. So, I don't know that we need to do
> anything other than finish implementing shared.

I meant something higher level so you don't even have to think about double-checked locking. Something like this:

	AssignOnce!(shared MyClass) c;
	c = { new shared MyClass }; // the delegate literal is called only the first time
	c.blahblah(); // c is guarantied to be initialized at this point

...or something similar.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On Sun, 18 Dec 2011 11:55:10 -0000, Michel Fortin <michel.fortin@michelf.com> wrote:

> On 2011-12-18 04:35:08 +0000, Jonathan M Davis <jmdavisProg@gmx.com> said:
>
>> On Saturday, December 17, 2011 22:16:38 Michel Fortin wrote:
>>> Shouldn't a properly implemented double-checked locking pattern be part
>>> of the standard library? This way people will have a better chance of
>>> not screwing up. I think the pattern is common enough to warrant it.
>>  Well, from the sounds of it, the basic double-checked locking pattern would
>> work just fine with a shared variable if shared were fully implemented, but
>> since it's not, it doesn't work right now. So, I don't know that we need to do
>> anything other than finish implementing shared.
>
> I meant something higher level so you don't even have to think about double-checked locking. Something like this:
>
> 	AssignOnce!(shared MyClass) c;
> 	c = { new shared MyClass }; // the delegate literal is called only the first time
> 	c.blahblah(); // c is guarantied to be initialized at this point
>
> ...or something similar.

Something like..
http://linux.die.net/man/3/pthread_once

I wrote a windows version of that once (pun intended), and I *think* it works .. after reading Andrei's link I'm not so sure..

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Regan Heath wrote:
> after reading Andrei's link I'm not so sure..

If Andrei's conclusions are correct, then they are correct even for
- the compilers under which an OS is compiled and
- the hardware on which the OS runs.

I.e. if there is a "you loose" for the application programmer then there is a "you loose" for the OS programmer and the engineer of the hardware too.

Does anyone except Andrei see what this means?

-manfred

Le 17/12/2011 08:47, Andrew Wiley a écrit :
> I was looking through Jonathan Davis's pull request to remove static
> constructors from std.datetime, and I realized that I don't know
> whether Double Checked Locking is legal under D's memory model, and
> what the requirements for it to work would be.
> (if you're not familiar with the term, check out
> http://en.wikipedia.org/wiki/Double-checked_locking - it's a useful
> but problematic programming pattern that can cause subtle concurrency
> bugs)
> It seems like it should be legal as long as the variable tested and
> initialized is flagged as shared so that the compiler enforces proper
> fences, but is this actually true?

Well according to the spec, it should work with the garantee given by shared.

But in real life, the compiler is unable to ensure that. This is compiler issue.

On Dec 19, 2011, at 7:18 AM, Manfred_Nowak wrote:

> Regan Heath wrote:
>> after reading Andrei's link I'm not so sure..
> 
> If Andrei's conclusions are correct, then they are correct even for
> - the compilers under which an OS is compiled and
> - the hardware on which the OS runs.
> 
> I.e. if there is a "you loose" for the application programmer then there is a "you loose" for the OS programmer and the engineer of the hardware too.
> 
> Does anyone except Andrei see what this means?

Not sure I understand the question, but if you look at the source of the Linux kernel, for example, it uses explicit memory barriers and other tricks to ensure a correct result.

Sean Kelly wrote:

> to ensure a correct result.

According to Andrei's paper, there is no ensurance of a correct result possible. If optimizations reduce runtime, then not only MTBF will be reduced, but some problems might turn out to be incomputable on that "optimized machine". Nobody will know in advance which problems that are.

Of course: this holds only if Andrei's conclusions in his paper are correct.

-manfred

On 1/4/12 6:55 PM, Manfred Nowak wrote:
> Sean Kelly wrote:
>
>> to ensure a correct result.
>
> According to Andrei's paper, there is no ensurance of a correct
> result possible. If optimizations reduce runtime, then not only MTBF
> will be reduced, but some problems might turn out to be incomputable
> on that "optimized machine". Nobody will know in advance which
> problems that are.
>
> Of course: this holds only if Andrei's conclusions in his paper are
> correct.
>
> -manfred

The conclusions only apply to portable C++2003 code.

Andrei