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
