Re: a little problem with atomic.h

From: Robert Jordens (rjo-lists_at_gmx.de)
Date: 08/08/03 12:27 EDT


From: Robert Jordens <rjo-lists@gmx.de>
Subject: Re: [ardour-dev] a little problem with atomic.h
Message-ID: <20030808162718.GA16462@schuh>
Date: Fri, 8 Aug 2003 18:27:18 +0200

Hello!

[Fri, 08 Aug 2003] Jack O'Quin
wrote/schrieb/�crivait/hai scritto/escribi�/scripsit:

> I would prefer some kind of compare-and-swap or exchange operation for
> this, but atomic.h does not provide one.  The comment about "not
> "bothering with" atomic.h was prompted by exactly the problems we are
> discussing.
> 
> > not sure of the right solution at this point.
> 
> As I see it, there are several options, all bad:
> 
>   1) use the system's <asm/atomic.h>
> 
>      This will (probably) work correctly on the machine for which you
>      are compiling.  But, distributions vary considerably in their
>      handling of machine-dependent headers like this one.  On my
>      Debian system it's included in the libc6-dev package.  Other
>      systems may package it with the kernel headers or even the kernel
>      source.  It will be hard to explain to users where to find it.

Yes. asm/atomic.h is a/depends on kernel headers. That should not be
used.

>   2) distribute your own copy
> 
>      This will never cover all possible machine architectures, SMP,
>      NUMA, etc.  But, it makes your package more self-contained.

There are even architectures where there is no possible userspace
implementation of atomic ops yet (arm and hppa as far as Debian is
concerned). Even for glibc!

gstreamer has some -- seemingly working -- implementations of atomic ops
in Userspace. It uses processor-specific stuff where possible and
mutexes for the rest.

glibc and postgresql are two other projects that use atomic ops.

>   3) distribute your own copy, but use the system one, if available
> 
>      This has some of the advantages of 1) and 2), but adds
>      maintenance uncertainty about which version is being used.

And cannot be used by binary packages!

> Personally, I dislike option 1) less than the others.

One quick question. What if HAVE_SMP is defined by _default_ in
atomic.h? Will that break on non-SMP systems?

For the debian packages I added the atomic ops code for m68k, mips, s390
and alpha. Those work. For hppa and arm non-atomic C-code is used
because the kernel headers use spinlocks and/or cli.

    Robert.

-- 
But it does move!
		-- Galileo Galilei


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
ardour-dev mailing list
ardour-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ardour-dev

This archive was generated by hypermail 2.1.7 : 08/08/03 12:34 EDT