Robert Haas <robertmh...@gmail.com> writes: > On Thu, Jun 26, 2014 at 6:20 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers