[fedora-arm] ARMv5 and atomic operations
Andrew Haley
aph at redhat.com
Tue Apr 24 16:01:29 UTC 2012
On 04/24/2012 04:49 PM, Nicolas Pitre wrote:
> On Tue, 24 Apr 2012, Andrew Haley wrote:
>
>> On 04/24/2012 12:39 PM, Nicolas Pitre wrote:
>>> On Tue, 24 Apr 2012, Andrew Haley wrote:
>>>
>>>> On 04/23/2012 09:31 PM, Nicolas Pitre wrote:
>>>>> On Mon, 23 Apr 2012, Andrew Haley wrote:
>>>>>
>>>>>> On 04/23/2012 06:36 PM, Thomas Meyer wrote:
>>>>>>> I'm running the Ubuntun 2.6.38 Tegra2 kernel (because of their fbdev
>>>>>>> support) on top of Fedora 17 armv5el on an Toshiba AC100 Laptop. The
>>>>>>> rsyslog package crashed everytime because of the missing kernel support
>>>>>>> of cmpxchg64. So when relying on the kernel helpers make sure that the
>>>>>>> resp. kernel support exists.
>>>>>>
>>>>>> Indeed. I had to write a workaround in IcedTea (i.e. java) on ARM for
>>>>>> just this reason. If you can't depend on a kernel helper being there I
>>>>>> can't see it's of any use.
>>>>>
>>>>> Kernel helpers don't disappear with time. You therefore can probe for
>>>>> their availability (see the documentation) in case the kernel support
>>>>> could be backported, or just refuse to run if the kernel version isn't
>>>>> recent enough. This is not much different from relying on a new
>>>>> syscall.
>>>>
>>>> Indeed it is. What would I gain from adding such a test? All I can
>>>> see is extra complication, untested code paths, and larger programs.
>>>
>>> What alternative do you have, other than not using any atomic
>>> operations?
>>
>> What I've done already: I have my own routines.
>
> You may get some atomicity with the SWP instruction, but that is not
> sufficient to implement atomic increments and the like.
>
> You may use the SWP to implement some locking and perform the "atomic"
> operations under the lock protection, but that doesn't work if atomic
> operations are also performed in signal handlers, and that scales badly
> if concurency is high.
>
> So that really depends what your atomic needs are. Implementing the
> latest library standards without any kernel help on ARMv5 or earlier is
> simply impossible. But custom code can get away with less.
Oh I see what you mean now. I'm inside the Java VM, so I can fall
back to locking if I'm on ARMv5; ldrexd is an optimization for doing
long-word updates rather than needed for correctness.
So, if I'm on v7 I have to have my own cmpxchg64 routines for older
kernels. I have to fall back to locks on older CPUs, because I still
want to work on old kernels too. I can't see any circumstances where
the kernel helper will be of any use.
Andrew.
More information about the arm
mailing list