On 5/19/2013 10:35 AM, deadalnix wrote:
On Sunday, 19 May 2013 at 13:13:07 UTC, Andrei Alexandrescu wrote:
No, the race condition would have stayed.

That is ridiculous. non nullable would have made the bug non existent, and even
without race condition the problem would exists. a reference is null, it
container shared, then set to something else. You can put barriers all over the
place to make that sequentially consistent that it wouldn't change anything and
the bug would still arise.

I agree with Andrei that eliminating null is not going to make a race condition into a thread safe one. You've got a serious bug that you may succeed in hiding by eliminating the null, but it's still there. From your description, I suspect the code is suffering from the double-checked locking bug (which can appear in very subtle forms).


You also never provided any convincing solution to the safety hole. We can't
even add check only on some edges cases as D also have values types. The only
solution we are left with that is really safe is to null check every dereference
or give up on @safe.

Please don't make us guess what exactly you mean by this.

Reply via email to