Although I can see how you think this looks like a double-check lock, what it actually looks like is: a dangerous double-check lock is broken too . Without a real implementation of SomeDataDoesNotExist and CreateSomeData for criticism, we have no guarantee that this thing is actually thread safe for each processor.
For an example of analyzing how a double-check lock might go wrong, check this broken and incorrect version of the double-check lock:
Manual Lock / Unlock C #
My advice: do not use any low-blocking technology for no good reason and review the code from a memory model expert; you are probably mistaken. Most people do.
In particular, do not use double-check locking if you cannot accurately describe what memory access reorders the processors can perform on your behalf and provide a convincing argument in favor of the correct solution, given any possible memory access reordering. At that moment, when you are a bit away from the known implementation, you need to start the analysis from scratch. You cannot assume that just because one double-check lock implementation is correct that all of them are; almost none of them are correct.
Eric Lippert
source share