On Friday, 1 February 2013 at 03:39:19 UTC, TommiT wrote:
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.
I'm familiar with the fact that programmers face endless woes
with regard to data-races. I thought that D has unshared data by
default. But since Array arr is defined in main instead of
outside main, therefore it is sharable between the two threads?
If two threads have access to the same data, what makes length as
a property different from length as an int? This problem may be
over my head for now...
