[haiku-development] Re: Non existing arch_atomic.h for ARM architectures
- From: Pawel Dziepak <pdziepak@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 14 Feb 2014 04:56:57 +0100
2014-02-10 10:24 GMT+01:00 Jonathan Schleifer
<js-haiku-development@xxxxxxxxxxx>:
> Am 08.02.2014 um 00:19 schrieb Pedro Pinto <pemdpinto@xxxxxxxxx>:
>
>> What would be the best way to solve these cases? Should a dummy
>> arm/arch_atomic.h be created?
>
> Another idea would be to implement those with the atomic builtins from GCC
> for everything except gcc2. This is most likely even faster, as if e.g. the
> return value is not used, GCC can optimize this.
Unfortunately, GCC atomic builtins won't help with any of the issues I
mentioned earlier. Actually, they may makes things even worse. If the
architecture does not support operations necessary to implement an
atomic_*() function helper is used instead. That's not a very bad
thing to do in user mode since in such case we have to fall back to
some kind of cooperation with the kernel in order to ensure atomicity.
However, to ensure atomicity in kernel mode on uniprocessor platforms
all that has to be done is to disable interrupts and there is no
reason not to completely inline atomic functions.
It is true that GCC builtins can result in a faster code when the
return is not needed (it doesn't affect LL/SC architectures in any
significant way, though; x86 seems to be the only victim) and that's
why definitely need to have separate atomic_*() and atomic_get_and_*()
functions.
Also, we already use GCC builtins (old style though) for some of the
atomic functions (cf. SupportDefs.h). However, as long as we use them
we are not able to rewrite atomic functions at runtime to take
advantage from CPU features (for x86: proper memory barriers instead
of lock add $0, (%esp) and perhaps TSX) that are available but not
guaranteed by the target architecture. I wouldn't consider this as a
long term solution.
Paweł
Other related posts:
