Word Tearing: Still a practical problem?
dsimcha
dsimcha at yahoo.com
Mon Mar 21 17:15:55 PDT 2011
On 3/21/2011 7:55 PM, nedbrek wrote:
> Hello all,
>
> "dsimcha"<dsimcha at yahoo.com> wrote in message
> news:im8d3b$j78$1 at digitalmars.com...
>> A few posts deep in the discussion on std.parallelism have prompted me to
>> double-check an assumption that I made previously. Is writing to adjacent
>> but
>> non-overlapping memory addresses concurrently from different threads safe
>> on
>> all hardware we care about supporting?
>>
>> I know this isn't safe on some DS9K-like architectures that we don't care
>> about, like old DEC Alphas. This is because the hardware doesn't allow
>> addressing of single bytes. I'm also aware of the performance
>> implications of
>> false sharing, but this is not of concern because, for the cases where
>> adjacent memory addresses are written to concurrently in std.parallelism
>> or
>> its examples, these are only a tiny fraction of writes and would not have
>> a
>> significant impact on performance.
>
> The main architectures (x86 and ARM) are both byte granular. Most embedded
> platforms are also byte granular. Alpha is the only architecture I am aware
> of that had this problem. Possibly other old/high performance ones...
> (Cray, 360, etc.)
>
> Ned
>
>
Excellent. I highly doubt we care about std.parallelism working on
embedded platforms. (Who the heck has a multicore embedded CPU anyway?)
My only other concern is that the compiler could in theory do strange
things that effectively increase granularity in some cases. I doubt any
would in practice. I'd feel much better if I had some official-looking
documentation, or at least assurance from Walter that DMD doesn't.
Better yet would be assurance from a compiler expert (i.e. Walter) that
all sanely implemented compilers for byte-granular hardware don't
increase memory granularity in practice, even if they don't officially
guarantee it.
More information about the Digitalmars-d
mailing list