On Sunday, 19 May 2013 at 23:07:00 UTC, deadalnix wrote:
On Sunday, 19 May 2013 at 22:32:58 UTC, Andrei Alexandrescu
wrote:
How was there a bug if everything was properly synchronized?
You either describe the matter with sufficient detail, or
acknowledge the destruction of your anecdote. This is going
nowhere.
I explained over and over. A field is initialized to null,
while the object lock is owned, and later to its value, while
it is locked. In the meantime, another thread access the
object, owning the lock, assuming the field is always
initialized.
The exact same problem arise quite often in the single threaded
world : a reference is set to null, the dev try to be clever
when initializing it, in a rare case it isn't, and everything
blows up when it occurs.
It is simply easier to reproduce when things are single
threaded, and are often quickly debugged in that case.
As explained, the multithreaded environment makes it super hard
to debug, not the primary cause of the issue. The simply
consistent in moving the initialization where it was set to
null in the first place.
It is an instance of the very classic something may be null and
code use it assuming it is never null.
So this is not a problem of nullableness - rather this is a
problem of mutability.