Re: better atomics - v0.5

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Ants Aasma <ants(at)cybertec(dot)at>
Subject: Re: better atomics - v0.5
Date: 2014-06-26 19:26:38
Message-ID: CAHyXU0zYtraVRMtsGsR8cP24T7UtV=bhVjR5atMXrHqu4H-VCQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 26, 2014 at 1:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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 wonder if this is true in all cases. The address you are locking
might be logically protected but at the same time nearby to other
memory that is under contention. In other words, I don't think you
can assume an atomic op locks exactly 4 bytes of memory for the
operation.

> 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.

Well not quite: you don't have the possibility of deadlock.

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabrízio de Royes Mello 2014-06-26 19:39:53 Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED
Previous Message Tom Lane 2014-06-26 19:11:36 Re: What's the point of json_extract_path_op etc?