Re: better atomics - v0.5
Merlin Moncure <mmoncure@gmail.com>
From: Merlin Moncure <mmoncure@gmail.com>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, 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-26T12:44:14Z
Lists: pgsql-hackers
On Thu, Jun 26, 2014 at 5: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 :). > > More seriously, I think we're not going to have much fun if we're making > up the rule that you can't do an atomic add/sub while a spinlock is > held. That just precludes to many use cases and will make the code much > harder to understand. I don't think we're going to end up having many > problems if we allow atomic read/add/sub/write in there. That rule seems reasonable -- why would you ever want to do this? While you couldn't properly deadlock it seems like it could lead to unpredictable and hard to diagnose performance stalls. merlin
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