Re: better atomics - v0.2

On 2013-11-19 09:57:20 -0500, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On point #2, I don't personally know of any systems that I care about
> > where inlining isn't supported. However, we've gone to quite a bit of
> > trouble relatively recently to keep things working for platforms where
> > that is the case, so I feel the need for an obligatory disclaimer: I
> > will not commit any patch that moves the wood in that area unless
> > there is massive consensus that this is an acceptable way forward.
> > Similarly for point #3: Heikki not long ago went to the trouble of
> > unbreaking --disable-spinlocks, which suggests that there is at least
> > some interest in continuing to be able to run in that mode. I'm
> > perfectly OK with the decision that we don't care about that any more,
> > but I will not be the one to make that decision, and I think it
> > requires a greater-than-normal level of consensus.
>
> Hm. Now that I think about it, isn't Peter proposing to break systems
> without working "inline" over here?
> http://www.postgresql.org/message-id/1384257026.8059.5.camel@vanquo.pezone.net

Hm. Those don't directly seem to affect our inline tests. Our test is
PGAC_C_INLINE which itself uses AC_C_INLINE and then tests that
unreferenced inlines don't generate warnings.

> Maybe that patch needs a bit more discussion. I tend to agree that
> significantly moving our portability goalposts shouldn't be undertaken
> lightly. On the other hand, it is 2013, and so it seems not unreasonable
> to reconsider choices last made more than a dozen years ago.

I don't think there's even platforms out there that don't support const
inlines, just some that unnecessarily generate warnings. But since
builds on those platforms are already littered with warnings, that
doesn't seem something we need to majorly be concerned with.

The only animal we have that doesn't support quiet inlines today is
HP-UX/ac++, and I think - as in patch 1 in the series - we might be able
to simply suppress the warning there.

> Here's an idea that might serve as a useful touchstone for making choices:
> compiler inadequacies are easier to fix than hardware/OS inadequacies.
> Even a dozen years ago, people could get gcc running on any platform of
> interest, and I seriously doubt that's less true today than back then.
> So if anyone complains "my compiler doesn't support 'const'", we could
> reasonably reply "so install gcc".

Agreed.

> On the other hand, if the complaint is
> "my hardware doesn't support 64-bit CAS", it's not reasonable to tell them
> to buy a new server.

Agreed. I've am even wondering about 32bit CAS since it's not actually
that hard to emulate it using spinlocks. Certainly less work than
arguing about removing stone-age platforms ;)

There's no fundamental issue with continuing to support semaphore based
spinlocks I am just wondering about the point of supporting that
configuration since it will always yield horrible performance.

The only fundamental thing that I don't immediately see how we can
support is the spinlock based memory barrier since that introduces a
circularity (atomics need barrier, barrier needs spinlocks, spinlock
needs atomics).

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services