On Wed, Mar 30, 2011 at 4:26 PM, Aldy Hernandez <al...@redhat.com> wrote:
>
>>> So... do you have any important targets in mind, because I don't see this
>>> being a problem for most targets?  As can be expected, I am only
>>> interested
>>> in x86*, powerpc*, and s390, especially since a cursory glance on other
>>> important targets didn't exhibit any problems.  However, given my target
>>> bias, I am willing to look into any important targets that are
>>> problematic
>>> (I'm hoping none :)).
>>
>> Well, I'm not sure that strict-align targets that provide byte access do
>> not simply hide the issue inside the CPU (thus, perform the
>> read-modify-write
>> there and do not guarantee any atomicity unless you ask for it).  It might
>> be even worse - targets might not even guarantee this for shared
>> cache-lines
>> (for non-ccNUMA architectures).  But I'm no expert here, but certainly
>> every possible weird CPU architecture has been implemented.
>
> Whoops, sorry I missed your off-list followup from yesterday (I'm reading
> mail sequentially :)):
>
>> Richard Guenther said:
>> strict-align targets will end up doing read-modify-write operations on
>> word-size even when accessing single bytes.  Note that some CPUs
>> have byte store operations but they usually are not guaranteed to
>> be "atomic" (thus, they simply do the read-modify-write in the CPU).
>> I am not aware of any strict-align CPU that can do atomic byte stores.
>>
>> Obvious problem when for example having multiple non-word-size
>> global vars (unless you force them to word-alignment).
>
> I was not aware of how this played out internally.  This is certainly a
> problem.  I will hunt down hardware for at least arm, sparc, and ia64, and
> investigate.  But it may be that the only option will be to disallow the C++
> memory model on strictly aligned hardware, or perhaps force word-alignment.
>
> Is forcing word-alignment too big of a hammer, or will the users for these
> architectures be content with having no support for the C++0x memory model?

I think a memory model that cannot be reasonably (read: also fast) implemented
on all HW is screwed from the start and we should simply ditch it.  Which
is because nobody will use it as you cannot rely on it when writing
portable programs or it will be hell slow.

Richard.

Reply via email to