[zeromq-dev] GCC Atomic Builtins (was Re: zmq on n900)
mato at kotelna.sk
Wed Feb 24 17:08:20 CET 2010
mato at kotelna.sk said:
> > Yes, I was just trying out maemo toolchain, this was not a perf test.
> > We don't have atomic ops for ARM, do we want to add them? or we could
> > use gcc builtin atomics. I think they added atomics in 4.1
> I'd forgotten about the gcc builtin atomics. If you can point me to
> somewhere that documents them that'd be useful.
The following note from David S. Miller is also useful:
As I see it, the GCC Atomic Builtins have a couple of disadvantages:
1) If they are not implemented on the target processor type, according to
the GCC documentation:
"If a particular operation cannot be implemented on the target
processor, a warning will be generated and a call an external function
will be generated. The external function will carry the same name as
the builtin, with an additional suffix `_n' where n is the size of the
This is not particularly useful since it makes testing for the availability
of said operations fairly tricky; we'd have to write autoconf tests that
attempt to compile and link a test program for each individual operation
Further (and this is confirmed by David Miller), the GCC builtins enforce a
full memory barrier for each operation which may not be what we want at
all and may in fact hurt performance in some cases.
If we did use the GCC builtins it'd have to be as a last fallback choice
before deciding on mutexes, so the autoconf detection process and
atomic_*.cpp would have to come up with an end result like this:
1) If we are using GCC (or a compatible compiler) and we are compiling for
an architecture for which we have a native implementation of atomics
(currently x86 and AMD64), use the native implementation.
2) If the OS supports atomic_ops(3) or similar (Solaris 9+, NetBSD 5.0,
Win32), use the OS implementation.
3) If we are using GCC and all the builtins we need are implemented by our
target architecture and GCC version/runtime, use the GCC bultin
4) Use mutexes.
At the moment we do 1), 2) and 4). Adding 3) is going to be a fair amount
of hairy preprocessor and autoconf work and lots of testing to make sure
that the combinations all work as expected. So I'm posting this to make
sure the information we need to make it work doesn't get lost, but I don't
expect to be working on this anytime soon.
If someone wishes to step up and produce a patch for review that will
satisfy all of the above, you're welcome to :-)
More information about the zeromq-dev