| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Markus Wanner <markus(at)bluegap(dot)ch> |
| Cc: | Aidan Van Dyk <aidan(at)highrise(dot)ca>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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:46:00 |
| Message-ID: | 2709.1290188760@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> Markus Wanner <markus(at)bluegap(dot)ch> writes:
>> Well, that certainly doesn't apply to full fences, that are not specific
>> to a particular piece of memory. I'm thinking of 'mfence' on x86_64 or
>> 'mf' on ia64.
> Hm, what do those do exactly?
I poked around in the Intel manuals a bit. They do have mfence (also
lfence and sfence) but so far as I can tell, those are only used to
manage loads and stores that are issued by special instructions that
explicitly mark the operation as weakly ordered. So the reason we're
not seeing bugs is presumably that C compilers don't generate such
instructions. Also, Intel architectures do guarantee cache consistency
across multiple processors (and it costs them a lot...)
I found a fairly interesting and detailed paper about memory fencing
in the Linux kernel:
http://www.rdrop.com/users/paulmck/scalability/paper/ordering.2007.09.19a.pdf
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ross J. Reedstrom | 2010-11-19 17:46:39 | Re: contrib: auth_delay module |
| Previous Message | Florian Weimer | 2010-11-19 17:14:17 | Re: Latches with weak memory ordering (Re: max_wal_senders must die) |