== Quote from dsimcha (dsim...@yahoo.com)'s article > == Quote from Michel Fortin (michel.for...@michelf.com)'s article > > > On second thought, no, but for practical, not theoretical reasons: > > > One, you can't introspect whether a foreach loop is using a ref or a > > > value parameter. This is an issue with how opApply works. > > Indeed a problem. Either we fix the compiler to support that, or we > > change the syntax to something like this: > > taskPool.apply(range, (ref int value) { > > ... > > }); > > Or we leave things as they are. > > > Two, AFAIK there's no way to get the native word size. > > Right. That's a problem too... you could probably alleviate this by > > doing a runtime check with some fancy instructions to get the native > > word size, but I'd expect that to be rather convoluted. > > I'd like to check if I understand that well. For instance this code: > > int[100] values; > > foreach (i, ref value; parallel(values)) > > value = i; > > would normally run fine on a 32-bit processor, but it'd create > > low-level a race on a 64-bit processor (even a 64-bit processor running > > a 32-bit program in 32-bit compatibility mode). And even that is a > > generalization, some 32-bit processors out there *might* have 64-bit > > native words. So the code above isn't portable. Is that right? > > Which makes me think... we need to document those pitfalls somewhere. > > Perhaps std.parallelism's documentation should link to a related page > > about what you can and what you can't do safely. People who read that > > "all the safeties are off" in std.parallelism aren't going to > > understand what you're talking about unless you explain the pitfalls > > with actual examples (like the one above). > This problem is **much** less severe than you are suggesting. x86 can address > single bytes, so it's not a problem even if you're iterating over bytes on a > 64-bit machine. CPUs like Alpha (which no D compiler even exists for) can't > natively address individual bytes. Therefore, writing to a byte would be > implemented much like writing to a bit is on x86: You'd read the full word > in, > change one byte, write the full word back. I'm not sure exactly how it would > be > implemented at the compiler level, or whether you'd even be allowed to have a > reference to a byte in such an implementation. This is why I consider this > more a > theoretical problem than a serious practical issue.
Actually, just remembered that word tearing is also an issue with unaligned memory access. I guess I could just include a warning that says not to do this with unaligned memory.