| 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: | Whole Thread | Raw Message | 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) |