| From: | Florian Weimer <fweimer(at)bfk(dot)de> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Markus Wanner <markus(at)bluegap(dot)ch>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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:14:17 |
| Message-ID: | 8239qx5j86.fsf@mid.bfk.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
* Andres Freund:
> I was never talking about 'locking the whole cache' - I was talking about
> flushing/fencing it like a "global" read/write barrier would. And "lock
> xchgb/xaddl" does not imply anything for other cachelines but its own.
My understanding is that once you've seen the result of an atomic
operation on i386 and amd64, you are guaranteed to observe all prior
writes performed by the thread which did the atomic operation, too.
Explicit fencing is only necessary if you need synchronization without
atomic operations.
--
Florian Weimer <fweimer(at)bfk(dot)de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-11-19 17:46:00 | Re: Latches with weak memory ordering (Re: max_wal_senders must die) |
| Previous Message | Tom Lane | 2010-11-19 17:13:48 | Re: Latches with weak memory ordering (Re: max_wal_senders must die) |