This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Implementing C++1x and C1x atomics
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