From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Alexey Klyukin <alexk(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Reducing overhead of frequent table locks |
Date: | 2011-05-27 21:01:51 |
Message-ID: | 3368.1306530111@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> When a strong lock is taken or released, we have to increment or
> decrement strong_lock_counts[fasthashpartition]. Here's the question:
> is that atomic? In other words, suppose that strong_lock_counts[42]
> starts out at 0, and two backends both do ++strong_lock_counts[42].
> Are we guaranteed to end up with "2" in that memory location or might
> we unluckily end up with "1"? I think the latter is possible... and
> some guard is needed to make sure that doesn't happen.
There are "atomic increment" primitives on most/all multiprocessors,
although availing ourselves of them everywhere will take an amount of
work not unlike developing the spinlock primitives :-(. You are dead
right that this is unsafe without that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2011-05-27 21:02:25 | Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch |
Previous Message | Robert Haas | 2011-05-27 20:55:07 | Re: Reducing overhead of frequent table locks |