Re: Implementing C++1x and C1x atomics

[Lawrence Crowl <crowl at google dot com>]

On 8/12/09, Joseph S. Myers <joseph@codesourcery.com> wrote:
> (moved from gcc-patches to gcc and libc-alpha)
>
> On Wed, 12 Aug 2009, Richard Guenther wrote:
> > On Aug 12, 2009, Boehm, Hans<hans.boehm@hp.com> wrote:
> > > [Partially replying to myself]
> > > > From:  Boehm, Hans
> > > >
> > > > At the risk of asking a stupid question, shouldn't all the
> > > > code inside gcc gradually migrate towards using the C++0x
> > > > (and probably C1x) atomics, which seem to be generally
> > > > supported by gcc 4.4?
> > > >
> > > > There are known issues with __sync (no atomic loads and
> > > > stores, underspecified ordering), which is why there wasn't
> > > > much of an effort to push the __sync interface into C++0x.
> > >
> > > OK.  That was largely a stupid question, since we're talking
> > > about the compiler implementation of those primitives, which
> > > presumably are shared with the atomic<T> implementation?

I worked very hard to C and C++ able to share the atomics.  If for
some reason we cannot share them, I want to know so that I can
fix it.

> > I'm not aware of a proper implementation of the C++1x atomics
> > or the memory model for gcc.

The atomic types and operations themselves are doable in relatively
short order, but the full memory model will take a while because
it requires that some optimizations change, which means auditing
the compiler back ends.

> And a proper implementation would sure have underlying built-in
> functions, added to the __sync_* set.

Or perhaps different names, but yes.

> The C1x atomics specification
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1349.htm> does
> not mention any amendment to the list of headers to be provided by
> freestanding implementations (clause 4 paragraph 6), which suggests
> that providing this header is actually in the domain of libc, not
> the compiler (which accords with it providing (generic) library
> functions, which the headers for freestanding implementations
> do not).  It seems clear however that close cooperation with the
> compiler will be needed in the implementation to ensure that the
> right semantics are available from the compiler for the header
> to use.

I think the C++ specification currently has the same problem.
The atomics are really a compiler issue.

> The information the compiler should provide the library would
> include which operations are available built-in or in libgcc
> and which the C library has to emulate with locks (if e.g. a
> particular architecture or subarchitecture does not have 64-bit
> atomic operations).  Given how many variations there are on what
> targets support and how, and given that what's supported may
> depend on -march etc. options passed when compiling code that
> includes the header, I think a single version of the header for
> all targets, that contains code conditional on various predefined
> macros, would be a good ideal to aim for.

The compiler must recognize all the atomic operations, so that it can
respect their implications, which means that they must be intrinsics.
Then there is direct instruction support for all the operations of
a type, it should emit that code.  When not, the compiler should
emit a call into a shared library that comes with the system.
You really do not want to take the risk of getting two different
implementations of the atomics.  They will fail to synchronize with
each other, and result in intermitent concurrency bugs.  Yuck.

> The compiler would also need to meet the underlying memory model
> requirements - avoiding optimizations that break the memory model
> assumptions (writes to locations that may not be written in the
> memory model, in particular) unless given an option to say it
> doesn't need to follow the model.

My recommendation is to just do a good enough job on _changing_
the optimizations so that you don't need an option.  It would
probably avoid some rather elusive bugs when someone links in a
library compiled the wrong way.

-- 
Lawrence Crowl