[PATCH] Fix __atomic to not implement atomic loads with CAS.
Ramana Radhakrishnan
ramana.radhakrishnan@foss.arm.com
Fri Feb 3 16:20:00 GMT 2017
On 03/02/17 15:13, Jakub Jelinek wrote:
> On Fri, Feb 03, 2017 at 04:07:22PM +0100, Torvald Riegel wrote:
>> On Fri, 2017-02-03 at 13:44 +0000, Ramana Radhakrishnan wrote:
>>> __atomic_load on ARM appears to be ok as well
>>>
>>> except for
>>>
>>> __atomic_load_di which should really be the ldrexd / strexd loop but we
>>> could ameliorate that similar to your option 3b.
>>
>> This uses just ldrexd now, and thus is not guaranteed to be atomic?
>>
>>> On AArch64
>>>
>>> * <16 byte loads have always been fine. The architecture allows single
>>> copy atomic loads using single load instructions for all other sizes and
>>> memory models, so we are fine there.
>>>
>>> * we have gone through the libatomic locks from day one of the port for
>>> 16 byte loads. This has been a bit of a bugbear for a number of users
>>> within ARM who would really like to get performance without heavy weight
>>> locks for 16 byte atomic ops.
>>
>> Would it be acceptable for those users to have loads that perform like
>> CAS loops, especially under contention? Or are these users more
>> concerned about aarch64 not offering a true atomic 16-byte load?
>
> Can the store you need for atomicity be into an automatic var on the stack?
No, it has to be to the same location.
Ramana
More information about the Gcc-patches
mailing list