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