Re: better atomics - v0.5

On 2014-06-30 12:54:10 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > ... this again is my point: why can't we make the same argument about
> > two spinlocks situated on the same cache line? I don't have a bit of
> > trouble believing that doing the same thing with a couple of spinlocks
> > could sometimes work out well, too, but Tom is adamantly opposed to
> > that.
>
> I think you might be overstating my position here. What I'm concerned
> about is that we be sure that spinlocks are held for a sufficiently short
> time that it's very unlikely that we get pre-empted while holding one.
> I don't have any particular bright line about how short a time that is,
> but more than "a few instructions" worries me. As you say, the Linux
> kernel is a bad example to follow because it hasn't got a risk of losing
> its timeslice while holding a spinlock.

Well, they actually have preemptable and irq-interruptile versions for
some of these locks, but whatever :).

> So ISTM the question we ought to be asking is whether atomic operations
> have bounded execution time, or more generally what the distribution of
> execution times is likely to be. I'd be OK with an answer that includes
> "sometimes it can be long" so long as "sometimes" is "pretty damn
> seldom".

I think it ranges from 'never' to 'sometimes, but pretty darn
seldom'. Depending on the platform and emulation.

And, leaving the emulation and badly written code aside, there's no
issue with another backend sleeping while the atomic variable needs to
be modified.

> Spinlocks have a nonzero risk of taking a long time already, since we
> can't entirely prevent the possibility of losing our timeslice while
> holding one. The issue here is just to be sure that that happens seldom
> enough that it doesn't cause performance problems. If we fail to do that
> we might negate all the desired performance improvements from adopting
> atomic ops in the first place.

I think individual patches will have to stand up to a test like
this. Modifying a atomic variable inside a spinlock is only going to be
worth it if it allows to avoid spinlocks alltogether in 95%+ of the
time.

Greetings,

Andres Freund

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