On Sunday, 19 May 2013 at 23:29:53 UTC, Walter Bright wrote:
On 5/19/2013 4:06 PM, 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.
so, you have:
==========================
Thread A Thread B
lock
p = null
Here p = null is implicit, this is part of the fun. The
initialisation is still properly synchronized.
unlock
lock
*p = ...
It was in java, so more somethign like p.foo(); But yes.
unlock
lock
p = new ...
unlock
==========================
Although you are using locks, it still isn't properly
synchronized. Changing the p=null to p=someothernonnullvalue
will not fix it.
No race condition exists in that program. The error lie in
improper initialization of p in the first place, which should
never has been null. The example looks dumb as this, you have to
imagine the pattern hidden in thousands of LOC.
The code is bugguy, but you'll find no undefined threading
effect? What happen is perfectly defined here and no thread
access shared data without owning the lock.
