Re: atomics.h may not be included from frontend code

On Tue, Feb 27, 2018 at 8:49 AM, Aleksander Alekseev
<a(dot)alekseev(at)postgrespro(dot)ru> wrote:
> We would like to know whether you share this concern and whether it
> would be a good idea to try to refactor the code so that atomics could
> be used not only from the backend.

I think the concern on the referenced threads was that atomics might
be implemented using spinlocks if we don't have a real atomics
implementation; and those in turn might be implemented as semaphores
if we don't have a real spinlock implementation. When we emulate
atomics using spinlocks, we use a fixed-size array of spinlocks stored
in shared memory; and when we emulate spinlocks using semaphore, we
use the semaphores in each PGPROC. So those emulation layers are
deeply tied into the backend's shared-memory architecture, and
untangling them might be a bit complicated.

However, those are presumably rare configurations that many people
(including many developers) don't care about. If #include "atomics.h"
worked from all frontend code except where one of those emulation
layers were in use, that would represent an improvement over the
current status quo for people doing out-of-core development against
PostgreSQL. On the other hand, it would also make it quite easy for
the use of atomics to creep into frontend code within PG itself, and
that's not OK so long as configurations that lack atomics and/or
spinlocks are considered supported. So that's something to think
about.

I have to imagine that systems which lack atomics and/or spinlocks are
almost extinct. It looks like we have at least one buildfarm member
running with each of --disable-spinlocks and --disable-atomics, but
systems that organically lack spinlocks and/or atomics must by now be
extremely rare. At some point, I think we should just de-support such
configurations, but I'm not sure if we're at that point yet.

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