Re: Module suggestion: Atomic operations

[Bruno Haible]

Hi Marc,

> At least one type in <stdatomic.h> is guaranteed to be
> lock-free, the atomic flag. Since C18, it can be used in signal
> handlers, where Posix locks won't work because they are not
> async-safe. Moreover, <stdatomic.h> provides memory fences, which I
> don't know how to emulate in general and which also seem to be crucial
> in signal handlers of multithreaded applications.
> 
> It seems to me that a substitute of <stdatomic.h> needs to know a bit
> about the underlying compiler (so that builtins can be used) or the
> underlying architecture (for example, x86 does not need memory fences
> with the release or acquire memory order. Unfortunately, my knowledge
> about other compilers than gcc or other architectures than x86 is
> limited. I could provide the skeleton of a substitute, but it would
> need other people to add their architectures.

Once things become compiler and architecture dependent, there are a
lot of (compiler, architecture) pairs to support. Using gcc/clang unless
mentioned otherwise:

  - i386: Linux, Solaris, macOS, Hurd, FreeBSD, NetBSD, OpenBSD, Haiku,
          Cygwin, mingw,
  - i386: Solaris (cc)
  - i386: Windows (MSVC)

  - x86_64: Linux, Solaris, macOS, FreeBSD, NetBSD, OpenBSD, Haiku,
            Cygwin, mingw,
  - x86_64: Solaris (cc)
  - x86_64: Windows (MSVC)
  - x86_64: Linux with x32 ABI (CC="gcc -mx32")

  - m68k: Linux

  - mips: Linux 32-bit, little-endian and big-endian
  - mips: Linux n32, little-endian and big-endian
  - mips: Linux 64-bit, little-endian and big-endian
  - mips: IRIX 6.5 (CC="gcc -mabi=n32")

  - sparc: Linux, Solaris, NetBSD
  - sparc: Solaris (cc)

  - sparc64: Linux, Solaris, NetBSD
  - sparc64: Solaris (cc)

  - alpha: Linux

  - hppa: Linux

  - arm: Linux

  - arm64: Linux, FreeBSD

  - powerpc: Linux, macOS, AIX
  - powerpc: AIX (xlc)

  - powerpc64: Linux (little-endian and big-endian), AIX
  - powerpc64: AIX (xlc)

  - ia64: Linux

  - s390: Linux

  - s390x: Linux

  - riscv32: Linux with ilp32d ABI.
  - riscv64: Linux with lp64d ABI.

It is a *lot* of work, alone to test these. If you have special code for
each of these platforms, we won't be done with it in any reasonable time.
Therefore it's essential, IMO, to use platform independent code as far as
possible.

Compiler builtins (of gcc and clang), like you suggest, are a good way to
support a large number of the platforms. But you also have to find a
solution for
  - Solaris (cc)
  - Windows (MSVC)
  - AIX (xlc)

For some of these, you can get an account on a test machine, see [1].

I agree that atomic flags and memory barriers are the essential ones (and
maybe hardest) to support.

You can leave testing to others, once the code is expected to work and
once you have provided good unit tests.

Bruno

[1] https://gitlab.com/ghwiki/gnow-how/-/wikis/Platforms/Machines