review of std.parallelism

[dsimcha]

On 3/21/2011 11:58 AM, dsimcha wrote:
> == Quote from dsimcha (dsimcha at yahoo.com)'s article
>> == Quote from Michel Fortin (michel.fortin at 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.

s/is/may be .  I'm trying to read up on word tearing and post questions 
here and to StackOverflow.  Good documentation about it seems 
ridiculously hard to come by.  About the only solid pieces of 
information I've found are that x86 definitely **can** do byte 
granularity (which doesn't mean it always does) and that Java makes 
these guarantees (which is only useful if you're writing in Java).  The 
general gut feeling people here and on StackOverflow seem to have is 
that it's not an issue, but there doesn't seem to be much backing up of 
this.

Maybe I'm just being paranoid and this is a complete non-issue except on 
the most obscure/ancient hardware and/or most stupidly implemented 
compilers, which is why few people even think of it.