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.
