Re: better atomics - v0.5 - Mailing list pgsql-hackers
From | Andres Freund |
---|---|
Subject | Re: better atomics - v0.5 |
Date | |
Msg-id | 20140626190405.GA21422@awork2.anarazel.de Whole thread Raw |
In response to | Re: better atomics - v0.5 (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: better atomics - v0.5
(Robert Haas <robertmhaas@gmail.com>)
|
List | pgsql-hackers |
On 2014-06-26 11:47:15 -0700, Tom Lane wrote: > 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. 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. > 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). With the code as submitted it's one spinlock per atomic variable. Which is fine until spinlocks are emulated using semaphores - in that case a separate array of semaphores (quite small in the patch as submitted) is used so there's no chance of deadlocks against a 'real' spinlock or anything like that. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
pgsql-hackers by date: