Low-Lock Singletons In D
Mehrdad
wfunction at hotmail.com
Mon May 6 23:47:39 PDT 2013
On Monday, 6 May 2013 at 18:56:08 UTC, Dmitry Olshansky wrote:
Thanks for the detailed explanation!
> And now compiler/CPU decides to optimize/execute out of order
> (again, it's an illustration) it as:
>
> lock _static_mutex;
> x = alloc int;
> //even if that's atomic
> static_ = x;
> // BOOM! somebody not locking mutex may already
> // see static_ in "half-baked" state
> x[0] = 42;
> unlock _static_mutex;
That's exactly the same as the classic double-checked lock bug,
right?
As I wrote in my original code -- and as you also mentioned
yourself -- isn't it trivially fixed with a memory barrier?
Like maybe replacing
_static = new ActualValue<T>();
with
var value = new ActualValue<T>();
_ReadWriteBarrier();
_static = value;
Wouldn't this make it correct?
>> Are't pointer writes always atomic?
>
> In short - no. Even not counting the world of legal
> re-ordering, unaligned writes
But my example was completely aligned...
More information about the Digitalmars-d
mailing list