This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Remove sparcv8 support
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date: Wed, 26 Oct 2016 16:02:50 -0200
>> I am not sure it is as simple as that. Even if the kernel makes sure
>> that an emulated CAS is atomic against another emulated CAS, it would
>> not guarantee atomicity against a plain store instruction on a different
>> CPU, right? For the emulated CAS to work on an SMP system I would think
>> the atomic_store_relaxed and atomic_store_release functions would also
>> need to be handled by the kernel, locking the write out when the CAS is
>> emulated, to keep the interaction linearizable.
>>
>
> I would expect kernel to emulate all the define atomic operation defined
> in ISA to provide correct atomic semantic. I am not really sure how
> feasible it would be, but the idea is from library standpoint running
> on a machine with a emulated atomic provided by kernel is semantic
> equal to running on a machine with hardware provided atomic.
>
> And I think it would be not feasible to keep pushing for C11 atomics
> on glibc if we can not guarantee it.
Plain stores would semantically not be allowed on such a shared value
anyways.
If atomicity is required, then nobody should do direct stores. Direct
stores are unchecked and non-atomic. Whether the kernel implements
the CAS or the cpu does it directly has no bearing on this issue.
All entities should always use the CAS operation to modify such values.