On 5/19/13 8:46 PM, Steven Schveighoffer wrote:
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.
One can only assume the entire point was to delay initialization of the
object to its first use/sharing point, so the changed pattern simply
initializes the object eagerly, thus missing the benefits of the
pattern. Otherwise that's an instance of the old adage "initialize
variables at the point of definition". That, granted, non-null
references do help with.
Andrei
