[libvirt] [PATCH] Improve on virAtomic implementation

[Eric Blake]

On 04/19/2012 02:09 PM, Stefan Berger wrote:
> This patch improves on the previously added virAtomicInt operations
> by testing for the compiler and if GCC >= 4.1 (not found in docs prior to
> that) is used on Linux and has the appropriate processor (that I have
> access to) then use the implementation based on the gcc-builtins.
> 
> I also did not look at other systems (cygwin, win32) that do not need
> access to virAtomic right now.
> 
> ---
>  src/util/viratomic.h |   88
> +++++++++++++++++++++++++++++++++++++++++----------
>  1 file changed, 72 insertions(+), 16 deletions(-)
> 
> Index: libvirt-acl/src/util/viratomic.h
> ===================================================================
> --- libvirt-acl.orig/src/util/viratomic.h
> +++ libvirt-acl/src/util/viratomic.h
> @@ -30,6 +30,22 @@
>  typedef struct _virAtomicInt virAtomicInt;
>  typedef virAtomicInt *virAtomicIntPtr;
> 
> +# define __VIR_ATOMIC_USES_LOCK
> +
> +# if defined(__GNUC__)
> +#  if ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 1)) || (__GNUC__ > 4)
> +#   if defined(__linux__)
> +#    if defined(__i386__) || defined(__x86_64__) || \
> +        defined(__powerpc64__) || defined(__powerpc__)

Overkill.  If you are compiling with gcc, you have access to the
compiler builtins on ALL platforms.  It is true that some platforms are
able to map the builtins to single assembly instructions, while other
platforms end up being calls into entry points provided by libgcc, but
the compiler takes care of all of that under the hood, without you
having to think about it.  There's no need to filter on OS or on
architecture; filtering on compiler is good enough.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120419/100ce985/attachment-0001.sig>