Low-Lock Singletons In D

This is an elegant solution to the double checked locking bug <a href="http://en.wikipedia.org/wiki/Double-checked_locking" rel="nofollow">http://en.wikipedia.org/wiki/Double-checked_locking</a>, incurring insignificant overhead.

Or you could use atomic swaps on the initialized bit. That's both cheaper and simpler.<p>psuedocode:<p><pre><code> member atomic32 init member mutex lock member obj ptr membarrier() if (atomic_load(&#38;init)) { return ptr } else { locked_init() atomic_save(&#38;init, 1) membarrier() } </code></pre> Not an expert, use this at your own risk.

Doesn't D have the ability to do stuff on class initialization? Or does it not initialize classes lazily?<p>In Java, this is how a threadsafe Singleton looks like:<p><pre><code> private static MySingleton instance = new MySingleton(); </code></pre> It will be initialized when the class is first used.<p>The whole double-checked locking and TLS thing is IMO a huge pointless smartassery contest in VM lawyering hinging on the eminently false premise that having singletons in a heavily multithreaded environment initialized sooner than they're used is a problem that anyone needs solved.<p>Whereas in reality, 90% of all applications don't need lazy loading, and for 90% of those that do, the above is lazy enough.

I don't think thread-local variables are necessary.<p>Consider a global flag that gets instantiated and synchronized across threads/cores to a state of 0 such that if it ever gets set to 1, it was after publishing and synchronizing the shared instance via a global pointer. This pointer, and the global flag, will not revert for the rest of the singleton's life (noted in the article) - so there is nothing to synchronize past that - and it is only for the guarding flag's 0 (unallocated) case that there is a question if things are synchronized. That check and potential allocation are what need a standard lock (provided by D's syncronized block), which the example already provides.