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-26T18:36:11Z
Lists: pgsql-hackers
On Thu, Jun 26, 2014 at 6:20 AM, Andres Freund <andres@2ndquadrant.com> wrote: > On 2014-06-25 20:16:08 -0400, Robert Haas wrote: >> On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund <andres@2ndquadrant.com> wrote: >> > Since it better be legal to manipulate a atomic variable while holding a >> > spinlock we cannot simply use an arbitrary spinlock as backing for >> > atomics. That'd possibly cause us to wait on ourselves or cause >> > deadlocks. >> >> I think that's going to fall afoul of Tom's previously-articulated "no >> loops inside spinlocks" rule. Most atomics, by nature, are >> loop-until-it-works. > > Well, so is TAS itself :). Yeah, which is why we have a rule that you're not suppose to acquire another spinlock while already holding one. You're trying to make the spinlocks used to simulate atomic ops an exception to that rule, but I'm not sure that's OK. An atomic op is a lot more expensive than a regular unlocked load or store even if it doesn't loop, and if it does loop, it's worse, potentially by a large multiple. -- 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