Double Checked Locking

[Sean Kelly]

Both concurrent execution and a compiler that assumes a single threaded execution model can do really weird things in the name of optimization. 

Sent from my iPhone

On Dec 17, 2011, at 3:03 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Saturday, December 17, 2011 09:50:26 Andrei Alexandrescu wrote:
>> On 12/17/11 1:56 AM, Andrew Wiley wrote:
>>> On Sat, Dec 17, 2011 at 1:47 AM, Andrew Wiley<wiley.andrew.j at gmail.com>  
> wrote:
>>>> 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?
>>> 
>>> This entry in the FAQ makes me suspicious:
>>> ```
>>> What does shared have to do with memory barriers?
>>> 
>>> Reading/writing shared data emits memory barriers to ensure sequential
>>> consistency (not implemented).
>>> ```
>>> 
>>> So DCL should be alright with data flagged as shared, but it's not
>>> implemented in the compiler?
>> 
>> That is correct.
> 
> 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?
> 
> - Jonathan M Davis