Double Checked Locking

Sean Kelly sean at invisibleduck.org
Sat Dec 17 06:23:23 PST 2011


No. The most efficient thing would be to use core.atomic atomicLoad!msync.acq() for the read and atomicStore!msync.rel() for the write. Use a temporary to construct the instance, etc. I think Andrei outlined the proper approach in a series of articles a while back. 

Sent from my iPhone

On Dec 16, 2011, at 11:47 PM, 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?


More information about the Digitalmars-d mailing list