Re: Atomics hardware support table & supported architectures - Mailing list pgsql-hackers

On Sat, Jun 14, 2014 at 9:12 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> At this year developer's meeting we'd discussed the atomics abstraction
> which is necessary for some future improvements. We'd concluded that a
> overview over the hardware capabilities of the supported platforms would
> be helpful. I've started with that at:
> https://wiki.postgresql.org/wiki/Atomics

That looks like a great start.  It could use a key explaining what the
columns mean.  Here are some guesses, and some comments.

single-copy r/w atomicity = For what word sizes does this platform
have the ability to do atomic reads and writes of values?  I don't
understand how "1" can ever NOT be supported - does any architecture
write data to memory a nibble at a time?  I also don't really
understand the *** footnote; how can you do kernel emulation of an
atomic load or store.
TAS = Does this platform support test and set?  Items in parentheses
are the instructions that implement this.
cmpxchg = Does this platform support compare and swap?  If so, for
what word sizes?  I assume "n" means "not supported at all" and "y"
means "supported but we don't know for which word sizes".  Maybe call
this column "CAS" or "Compare and Swap" rather than using an
Intel-ism.
gcc support from version = Does this mean the version from which GCC
supported the architecture, or from which it supported atomics (which
ones?) on that architecture?

> Does somebody want other columns in there?

I think the main question at the developer meeting was how far we want
to go with supporting primitives like atomic add, atomic and, atomic
or, etc.  So I think we should add columns for those.

> From that and previous discussions
> (e.g. http://archives.postgresql.org/message-id/20131013004658.GG4056218%40alap2.anarazel.de
> ) I think we should definitely remove some platforms:
> 1) VAX. Production ceased 1997. We've never supported OpenVMS, just
> netbsd (and probably openbsd)

Based on the letter you linked from the Wiki page, I am inclined to
agree.  The letter lists the final ship date for the last surviving
type of VAX as December 31, 2000, with support ending in 2010.  It
seems unlikely that anyone will wish to run a version of PostgreSQL
released in 2015 on such hardware (and if they do, we can make that
their problem rather than ours).

> 2) m32r. Our implementation depends on an *unmerged* glibc header. The
> website was dead for several *years*, even after the restore patches
> can't be downloaded anymore (404).

That is also an excellent argument for deprecation.

> 3) sparcv8: Last released model 1997.

I seem to recall hearing about this in a customer situation relatively
recently, so there may be a few of these still kicking around out
there.

> 4) i386: Support dropped from windows 98 (yes, really), linux, openbsd
>    (yes, really), netbsd (yes, really). No code changes needed.

Wow, OK.  In that case, yeah, let's dump it.  But let's make sure we
adequately document that someplace in the code comments, along with
the reasons, because not everyone may realize how dead it is.

> 5) pa-risc.

This is a bit less dead than the other ones; support for existing
system only stopped at the end of 2013.  But I don't personally have a
reason to keep it alive.

> 6) armv-v5

I think this is also a bit less dead than the other ones; Red Hat's
shows Bugzilla shows people filing bugs for platform-specific problems
as recently as January of 2013:

https://bugzilla.redhat.com/show_bug.cgi?id=892378

> Note that this is *not* a requirement for the atomics abstraction - it
> now has a fallback to spinlocks if atomics aren't available.

That seems great.  Hopefully with a configure option to disable
atomics so that it's easy to test the fallback.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company