The kernel has used a set of spinlocks to help dealing with atomics in certain conditions (architecture, length of bitfield...). A discussion on what atomi operations are needed may be of value to ODP too: https://lwn.net/Articles/695257/
On 23 January 2017 at 10:49, Joe Savage <joe.sav...@arm.com> wrote: > > Any atomics can be emulated in SW (using compiler built-ins or locks > directly). The point here is the missing HW support: > > * E.g. MIPS, Power, ARMv7 do not have 128 bit CAS > > * 128 bit fetch-and-add is not supported in any of the architectures > > > > We need to ensure on any operations added that those can be implemented > efficiently on most of the targets. > > Yes, I totally appreciate that this is important with respect to adding > 128-bit support to the ODP atomics API. In terms of this example in > particular, though, I would think that the more important factor is having > support for the built-ins at all. After all, this isn't for performance > measurement, but is merely an illustrative demonstration of fragmentation > and > reassembly using ODP. And we don't want to break builds without support. > > That being said, it would be nice if the performance was relatively > acceptable in general in order to provide a more realistic view of what > might > be used in real systems. I believe that to be the case here, even for > 32-bit > machines, where 64-bit rather than 128-bit atomics are used. (This is good > news for ARMv7 at least — I'm not sure if it helps MIPS out.) > > Unfortunately, there is a further complication here in that the doubleword > (ARMv7) and quadword (ARMv8) atomic primitives aren't always there by > default > either. In my working copy, I'm currently bundling along lock-free 64-bit > and > 128-bit CAS implementations to fill this purpose for ARMv7 and ARMv8 > respectively. This is a slight annoyance, but saves a dependency on the > external "libatomic" and gives a more efficient implementation than the > lock-based solution used within this. > -- [image: Linaro] <http://www.linaro.org/> François-Frédéric Ozog | *Director Linaro Networking Group* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog