Re: better atomics - v0.5
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Geoghegan <pg@heroku.com>,
Pg Hackers <pgsql-hackers@postgresql.org>, Ants Aasma <ants@cybertec.at>
Date: 2014-06-27T17:15:25Z
Lists: pgsql-hackers
On Thu, Jun 26, 2014 at 3:04 PM, Andres Freund <andres@2ndquadrant.com> wrote: > I don't really see usecases where it's not related data that's being > touched, but: The point is that the fastpath (not using a spinlock) might > touch the atomic variable, even while the slowpath has acquired the > spinlock. So the slowpath can't just use non-atomic operations on the > atomic variable. > Imagine something like releasing a buffer pin while somebody else is > doing something that requires holding the buffer header spinlock. If the atomic variable can be manipulated without the spinlock under *any* circumstances, then how is it a good idea to ever manipulate it with the spinlock? That seems hard to reason about, and unnecessary. Critical sections for spinlocks should be short and contain only the instructions that need protection, and clearly the atomic op is not one of those. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Avoid the use of a separate spinlock to protect a LWLock's wait queue.
- 008608b9d510 9.6.0 cited
-
Improve LWLock scalability.
- ab5194e6f617 9.5.0 cited
-
Reduce the number of semaphores used under --disable-spinlocks.
- daa7527afc22 9.4.0 cited
-
Alter the configure script to fail immediately if the C compiler does not
- d15cb38dec01 9.0.0 cited