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.