Re: better atomics - v0.5 - Mailing list pgsql-hackers

On 2014-06-28 19:36:39 +0300, Heikki Linnakangas wrote:
> On 06/27/2014 08:15 PM, Robert Haas wrote:
> >On Thu, Jun 26, 2014 at 3:04 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> >>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.
> >
> >If the atomic variable can be manipulated without the spinlock under
> >*any* circumstances, then how is it a good idea to ever manipulate it
> >with the spinlock?
> 
> With the WALInsertLock scaling stuff in 9.4, there are now two variables
> protected by a spinlock: the current WAL insert location, and the prev
> pointer (CurrBytePos and PrevBytePos). To insert a new WAL record, you need
> to grab the spinlock to update both of them atomically. But to just read the
> WAL insert pointer, you could do an atomic read of CurrBytePos if the
> architecture supports it - now you have to grab the spinlock.
> Admittedly that's just an atomic read, not an atomic compare and exchange or
> fetch-and-add.

There's several architectures where you can do atomic 8byte reads, but
only busing cmpxchg or similar, *not* using a plain read... So I think
it's actually a fair example.

> Or if the architecture has an atomic 128-bit compare &
> exchange op you could replace the spinlock with that. But it's not hard to
> imagine similar situations where you sometimes need to lock a larger data
> structure to modify it atomically, but sometimes you just need to modify
> part of it and an atomic op would suffice.

Yes.

> I thought Andres' LWLock patch also did something like that. If the lock is
> not contended, you can acquire it with an atomic compare & exchange to
> increment the exclusive/shared counter. But to manipulate the wait queue,
> you need the spinlock.

Right. It just happens that the algorithm requires none of the atomic
ops have to be under the spinlock... But I generally think that we'll
see more slow/fastpath like situations cropping up where we can't always
avoid the atomic op while holding the lock.

How about adding a paragraph that explains that it's better to avoid
atomics usage of spinlocks because of the prolonged runtime, especially
due to the emulation and cache misses? But also saying it's ok if the
algorithm needs it and is a sufficient benefit?

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services