Re: [boost] Notice: Boost.Atomic (atomic operations library)

Subject: Re: [boost] Notice: Boost.Atomic (atomic operations library)
From: Helge Bahmann (hcb_at_[hidden])
Date: 2009-11-30 12:08:50

Hi Phil!

Thanks for your interest, and I appreciate any help for Arm, as I don't have 
this architecture available.

Am Monday 30 November 2009 17:02:14 schrieb Phil Endecott:
[snip]
> Architecture v6 introduced 32-bit load-locked/store-conditional
> instructions. Architecture v7 introduced 16- and 8-bit versions. 

The library already has infrastructure in place to emulate 8- and 16-bit 
atomics by "embedding" them into a properly aligned 32-bit atomic 
(created "on the fly" through appropriate pointer casts). FWIW ppc and Alpha 
require this already, as they do not have 8/16-bit ll/sc. This is of course 
slower than native 8-/16-bit versions, but is workable.

I will shortly be adding a small howto on adding platform support to the 
library.

> ARM Linux has kernel support that provides compare-and-swap even on
> processors that don't support it by guaranteeing to not interrupt code
> in certain address ranges.  This has the cost of a function call, i.e.
> it's slower than inline assembler but a lot faster than a system call.
> Kernels that don't support this are now sufficiently old that I think
> they can be ignored.  Newer versions of gcc may use this mechanism when
> the atomic builtins are used, but versions of gcc that don't do this
> are sufficiently widespread that they should still be supported
> efficiently.

these functions are part of libc, glibc or the vdso?

> I believe that OS X on ARM (i.e. the iPhone) always runs on
> architecture v6 or newer.  However Apple supply a version of gcc that
> is too old to support ARM atomics via the builtins.  The "recommended"
> way to do atomics is via a set of function calls described here: 
> http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPa
>ges/man3/atomic.3.html I have not looked at what these functions do or tried
> to benchmark them.  They are also available on other OS X platforms.

these should easily be usable, but
- the *Barrier versions are still stronger than what is required (see below)
- there are no "Load with Barrier" and "Store with Barrier" operations, these 
would have to be emulated with compare_exchange

> I note that you don't seem to use the gcc atomic builtins even on
> platforms where they have worked for a while e.g. x86.  Any reason for
> that?

on x86 it would not matter; on all other platforms, the intrinsics have the 
unfortunate side-effect of always acting as (usually bi-directional) memory 
barriers. There are however legitimate use cases, for example the following 
operation (equivalent to __sync_fetch_and_add):

        atomic<int>::fetch_add(1, memory_order_acq_rel)

is 2 to 3 times slower on ppc than the version not enforcing memory ordering:

        atomic<int>::fetch_add(1, memory_order_relaxed)

If you always use fully-fenced versions, then any lock-free algorithm will 
usually be noticeably *slower* than the platform's native mutex lock/unlock 
operation (which use only the weakest barriers necessary), making the whole 
exercise rather pointless.

Cheers Helge