Re: Implementing C++1x and C1x atomics

[Lawrence Crowl <crowl at google dot com>]

On 8/14/09, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Fri, 14 Aug 2009, Lawrence Crowl wrote:
> > 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?
>
> (I will suppose that by "compile ... on a processor of type D" you
> mean compile with the compiler told to target D (explicitly with
> -march=D, or implicitly with -march=native, or with a compiler
> configured --with-arch=D), since the processor of the target is
> in general independent of that of the host.)

Yes.

> 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.

Yuck.

> Ways for the kernel or dynamic linker to detect such
> incompatibilities may be useful, but would apply to this issue
> in general, not specifically to atomic operations.

The difference with the atomics is that if an application uses the
D instructions, we also need the dynamic library to also use the
D instructions (on a D or later processor).  How do we ensure that?

If we cannot, then I am concerned that we would be able to inline
no atomic operations without dropping support for the 80386 as
a subset of the later processors.  The same situation applies to
other processor families.

-- 
Lawrence Crowl