On Sun, 19 May 2013 16:03:24 -0400, Andrei Alexandrescu
<[email protected]> wrote:
On 5/19/13 3:36 PM, deadalnix wrote:
I described a very usual null bug : something is set to null, then to a
specific value. It is assumed not to be null. In a specific case it is
null and everything explode.
The concurrent context here made it especially hard to debug, but isn't
the cause of the bug.
Additionally, if you don't have enough information to understand what
I'm saying, you are perfectly allowed to ask for additional details This
isn't a shame.
Your argument has been destroyed so no need to ask details about it.
Replace "null" with "invalid state" and it's the same race in any
system. Let's move on.
I just wanted to chime in with this understanding of the bug that I am
reading from deadalnix's descriptions:
SomeObj obj;
shareTheObj(&obj); // goes to other threads
obj = new SomeObj; // initialize obj
This is likely simpler than the actual problem, but I think this is the
gist of it.
A Non-Nullable solution WOULD solve the race:
SomeObj obj; // Compiler: nope, can't do that, must initialize it.
Now, with an "invalid state" not available like null, is the developer
more likely to go through the trouble of building an invalid state for
obj, in order to keep the racy behavior? No. He's just going to move the
initialization:
SomeObj obj = new SomeObj;
shareTheObj(&obj);
In essence the point of the anecdote is that a Non-Nullable reference
would have PROMOTED avoiding the race condition -- it would have been
harder to keep the racy behavior.
I'm not saying that I think we need NN references as a compiler-supported
type, or that it needs to be the default, or that NN references ALWAYS
solve race conditions. I'm just pointing out what I see is an obvious
misinterpretation of the underlying story.
-Steve
