Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)

[deadalnix]

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.