Re: Implementing C++1x and C1x atomics

[Lawrence Crowl <crowl at google dot com>]

On 8/19/09, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Wed, 19 Aug 2009, Lawrence Crowl wrote:
>
>  > I am quoting from several different messages.
>  >
>  > On 8/17/09, Joseph S. Myers <joseph@codesourcery.com> wrote:
>  > > (A) Code compiled against headers from libc version X must be run
>  > > with libc version X or later.
>  >
>  > What is the symptom of failing to meet this constraint?
>
>
> Depending on what features the code uses and when you pass it to the
>  static linker, there may be errors from the static linker or the dynamic
>  linker, misbehavior at runtime (e.g. if you pass a new flag to a function
>  that doesn't know about that flag in the old libc) or no symptoms.
>
>
>  > > > So, suppose I compile my program A, using libc version X, on
>  > > > a processor of type D, which permits me to inline the atomic
>  > > > operations.  Then suppose that I execute A on a processor of
>  > > > type E, which has libc version X, but which supports fewer
>  > > > atomic operations and thus requires a locking implementation.
>  > > > I have met all the versioning requirements.  What happens?
>  > >
>  > > You get SIGILL when the atomic instruction that is present on D
>  > > but not E is executed.  That a program built for one processor
>  > > (D) but executed on another (E), whose features are not a superset
>  > > of those of D, will get SIGILL, or execute incorrectly if E does
>  > > something else on encountering that instruction, is not in any way
>  > > specific to atomic instructions; it applies to every architecture
>  > > with more than one supported variant.
>  >
>  > There is a very similar scenario, that is problematic.  Suppose that
>  > the application A uses only instructions from E.  It will execute every
>  > instruction correctly, but because the application uses a non-locking
>  > implementation and the library uses a locking implementation, there
>  > will be synchronization failure.
>
>
> If you built with -march=E, the library should not have told the compiler
>  that it could inline the atomic operations.
>
>
> > > I have suggested that the library inform the compiler, via its headers
> > > (whatever the details - pragmas, macros, etc. - and whether or not
> > > the header in question is implicitly preincluded) of whether the
> > > library will be using these instructions, with the compiler making
> > > safe assumptions if the library does not give it this information.
> > > (The information passed from the library to the compiler would be an
> > > assertion that that library version, and all later versions, when
> > > used on a D or later processor, will always use the D instructions
> > > or later instructions that safely interoperate with them.)
> >
> > Is this header provided with the compiler or the operating system?
> > In part, I am concerned about gcc on non-Linux systems.
>
> The header would be provided by the provider of the library which
> includes any out-of-line atomic functions that may be lock-based,
> which we had previously concluded would be libc (rather than
> libgcc) on Linux systems.  (We also concluded that the set of
> such functions and their names would be considered part of the
> platform ABI for that system.)  If the OS provides a header that
> is not suitable for GCC then it may need fixing with fixincludes.

Okay.  Just to be clear, any lock-based implementation should exist
only in the library, never inlined.

> This works best for C++ if we do not try to support the C++ atomics
> (or at least those that might need lock-based implementations)
> in the absence of libc support for the C atomics; certainly it
> seems lock-based implementations in libstdc++ must be avoided to
> avoid conflict with such implementations in libc.

Agreed 100%.  The intent was that all the C++-specific stuff be
implemented in terms of the C-specific stuff, independent of the
platform.

-- 
Lawrence Crowl