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