Double Checked Locking
sean at invisibleduck.org
Sat Dec 17 15:49:06 PST 2011
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>
>>>> 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
>>>> 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
More information about the Digitalmars-d