Re: gcc 4.1 implements compiler builtins for atomic ops

["David S. Miller" <davem at davemloft dot net>]

From: Ulrich Drepper <drepper@redhat.com>
Date: Sun, 26 Jun 2005 16:38:29 -0700

> And go, beat up the processor people.  They cause the problems.  We
> cannot have everybody else suffer from that.

What if your "cool, worthwhile" majority ends up being the cause
of this suffering in the future?

GLIBC and the kernel have bugs too, bugs which people end up having to
work around to get things working in their environment.

And just like with GLIBC and the kernel, many people have made a large
investment in the cpus they have and can't just "upgrade" or send some
hate mail to the "processor people".  Processor people work just as hard,
if not harder, on avoiding bugs.  In fact, they have to deal with harder
engineering problems than us lame software engineers have to such as
the speed of light and electrical signal propagation.  So if anything,
give the "processor people" a break when a bug slips through from time
to time.

Processors have bugs, and processors will have bugs.  We have ways to
cleanly supply processor specific routines so that the bugs can be
properly worked around, and the expensive workarounds can be avoided
when possible.

The kernel vDSO area, and glibc, are places where this should happen.

Ignoring processor bug issues, different processors allow optimizing
these primitives in various subtle ways.  We should be able to take
advantage of that as well.

I totally agree with BenH, this stuff does not belong in the compiler.

If, as a not-so-hypothetical example, some years from now the
Pentium-1000 has some subtle atomic operation bug that needs a proper
workaround, are you telling me that you think it's OK that one needs
to recompile every single binary on their system using atomic
operations in order for things to work?

This, to me, sounds like a good setup for disaster.

We don't ask users to recompile their binaries just to take advantage
of some new memcpy() technique a new version of a processor provides.
There is nothing different about atomic operations in this regard.

I'm sorry if you feel that this is another case of the "lame minority"
holding back the "cool majority", but not doing atomics in glibc or
the vDSO page is totally inconsistent wrt. how we handle this kind of
problem in other areas such as memcpy, memset, gettimeofday() et al.

It also means that if the "cool majority" needs the flexibility in the
future to work around a processor bug, we've painted ourselves into
a corner and have to recompile all of our binaries to get things working.

We shouldn't put this into the compiler, for the same reason that we
don't expose FILE layout internals in the glibc header files that
applications make use of just to make getc()/putc() a few cycles
faster.