Possible @property compromise

[TommiT]

On Friday, 1 February 2013 at 03:13:42 UTC, Zach the Mystic wrote:
> On Friday, 1 February 2013 at 02:27:30 UTC, TommiT wrote:
>> And here's another example of why it is as big of a problem as 
>> I make it sound to be:
>>
>> import std.concurrency;
>>
>> struct Array
>> {
>>    int _len;
>>
>>    length struct // Using Zach's syntax
>>    {
>>        @property get() { return _len; }
>>        alias this = get;
>>        void opAssign(int rhs) { _len = rhs; }
>>    }
>> }
>>
>> void func(T)(T t)
>> {
>>    auto v = t;
>>    v = 10;
>> }
>>
>> void main()
>> {
>>    Array arr;
>>    spawn(&func!int, arr.length);
>>    arr.length = 20; // And here we have a data-race.
>>                     // Good luck trying to find these
>>                     // kinds of bugs.
>> }
>
> I'm sorry, I know very little about race conditions. If you 
> might explain just a little bit about what is happening here, 
> I'd be in a better position to understand what you're saying. I 
> really can't say anything other than please describe what this 
> does and why it's a problem at this time.

spawn(&func!int, arr.length);

...creates a new thread and runs the following function call in 
it:
func!(int)(arr.length)

While that function call is evaluating in the new thread, the old 
thread may simultaneosly execute:
arr.length = 20;

Since both of those threads end up at some point calling 
arr.length.opAssign and therefore both of them may assign to 
arr._len simultaneously, that's a data-race. It would be 
data-race also if only one of them wrote to it and the other one 
just read it.