| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
| Cc: | Greg Stark <stark(at)mit(dot)edu>, Jeff Davis <pgsql(at)j-davis(dot)com>, Thom Brown <thom(at)linux(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Re: memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs) |
| Date: | 2011-09-24 16:46:48 |
| Message-ID: | CA+TgmoZYiA70M+efY785_j-camFi+NY7cSNWcoNY09JJpoqRNA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Sep 24, 2011 at 9:45 AM, Martijn van Oosterhout
<kleptog(at)svana(dot)org> wrote:
> I think memory accesses are also fantastically expensive, so it's worth
> some effort to optimise that.
This is definitely true.
> I found the Linux kernel document on this topic quite readable. I think
> the main lesson here is that processors track data dependancies (other
> than the Alpha apparently), but not control dependancies. So in the
> example, the value of i is dependant on num_items, but not via any
> calculation. IThat control dependancies are not tracked makes some
> sense, since branches depend on flags bit, and just about any
> calculation changes the flag bits, but most of the time these changes
> are not used.
Oh, that's interesting. So that implies that a read-barrier would be
needed here even on non-Alpha.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-09-24 16:46:59 | Re: Large C files |
| Previous Message | Robert Haas | 2011-09-24 16:42:54 | Re: unite recovery.conf and postgresql.conf |