| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Ants Aasma <ants(at)cybertec(dot)at> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Freezing without write I/O |
| Date: | 2013-10-01 11:13:55 |
| Message-ID: | 20131001111355.GF2670970@alap2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2013-10-01 04:47:42 +0300, Ants Aasma wrote:
> I still think we should have a macro for the volatile memory accesses.
> As a rule, each one of those needs a memory barrier, and if we
> consolidate them, or optimize them out, the considerations why this is
> safe should be explained in a comment. Race prone memory accesses
> should stick out like a sore thumb.
Agreed. The "wait free LW_SHARED" thing[1] I posted recently had a simple
#define pg_atomic_read(atomic) (*(volatile uint32 *)&(atomic))
That should be sufficient and easily greppable, right?
I generally think we need to provide some primitives for doing atomic
stuff. There's lots of stuff that's not easy to accelerate further without.
Greetings,
Andres Freund
[1] http://archives.postgresql.org/message-id/20130926225545.GB26663%40awork2.anarazel.de
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2013-10-01 11:26:01 | Re: Cmpact commits and changeset extraction |
| Previous Message | Andres Freund | 2013-10-01 11:08:35 | Re: [PERFORM] Cpu usage 100% on slave. s_lock problem. |