Re: better atomics - v0.5
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@2ndquadrant.com>, Peter Geoghegan <pg@heroku.com>,
Pg Hackers <pgsql-hackers@postgresql.org>, Ants Aasma <ants@cybertec.at>
Date: 2014-06-26T18:47:15Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes: > 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: >>> 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. Well, the point here is to be sure that there's a reasonably small bound on how long we hold the spinlock. It doesn't have to be zero, just small. Would it be practical to say that the coding rule is that you can only use atomic ops on fields that are protected by the spinlock, ie, nobody else is supposed to be touching those fields while you have the spinlock? If that's the case, then the atomic op should see no contention and thus not take very long. On the other hand, if the atomic op is touching something not protected by the spinlock, that seems to me to be morally equivalent to taking a spinlock while holding another one, which as Robert says is forbidden by our current coding rules, and for very good reasons IMO. However, that may be safe only as long as we have real atomic ops. If we're simulating those using spinlocks then you have to ask questions about how many underlying spinlocks there are and whether artificial contention might ensue (due to the same spinlock being used for multiple things). regards, tom lane
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