From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Aidan Van Dyk <aidan(at)highrise(dot)ca>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com> |
Subject: | Re: Latches with weak memory ordering (Re: max_wal_senders must die) |
Date: | 2010-11-19 17:13:48 |
Message-ID: | 2132.1290186828@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:
> I think it would be useful to try to build up a library of primitives
> in this area. For this particular task, we really only need a
> write-with-fence primitive and a read-with-fence primitive.
That's really entirely the wrong way to think about it. You need a
fence primitive, full stop. It's a sequence point, not an operation
in itself. It guarantees that reads/writes occurring before or after
it aren't resequenced around it. I don't even understand what "write
with fence" means --- is the write supposed to be fenced against other
writes before it, or other writes after it?
> I think it would also be useful to provide macros for
> compare-and-swap and fetch-and-add on platforms where they are
> available.
That would be a great deal more work, because it's not a no-op anywhere;
and our need for it is still rather hypothetical. I'm surprised to see
you advocating that when you didn't want to touch fencing a moment ago.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Weimer | 2010-11-19 17:14:17 | Re: Latches with weak memory ordering (Re: max_wal_senders must die) |
Previous Message | Robert Haas | 2010-11-19 17:06:55 | Re: Latches with weak memory ordering (Re: max_wal_senders must die) |