Hi,
On 2018-02-27 10:36:01 -0500, Robert Haas wrote:
> On Tue, Feb 27, 2018 at 8:49 AM, Aleksander Alekseev
> We tried to follow commit messages [1] and discussions [2]. However no matter
> how you try to look on this code it's weird.
I don't see how that makes the code weird. Not fit for your purpose,
sure, but weird?
> > 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.
Right.
> However, those are presumably rare configurations that many people
> (including many developers) don't care about.
I don't think that's quite true anymore. We e.g. now rely on 64bit
atomics being emulated on some machines, and they're unavailable on a
bigger number of systems than atomics proper, particularly 32bit
sytems. There's also hppa, of course ;)
> 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.
I think if we wanted to enable this code to be used from frontend, we'd
have to to implement the various fallbacks paths in a bit different way,
so they can be supplied by frontend code. And then we can rely on it on
frontend code for real, if we want to.
Greetings,
Andres Freund