On Tue, Feb 27, 2018 at 8:49 AM, Aleksander Alekseev <a.aleks...@postgrespro.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
