Re: Spinlocks and compiler/memory barriers

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Spinlocks and compiler/memory barriers
Date: 2014-06-30 22:28:54
Message-ID: 20140630222854.GW26930@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-06-30 19:22:59 +0200, Andres Freund wrote:
> On 2014-06-30 12:46:29 -0400, Robert Haas wrote:
> >, which if I understand you correctly are ARM without GCC
> > atomics, Sparc, and MIPS.
>
> I've to revise my statement on MIPS, it actually looks safe. I seem to
> have missed that it has its own S_UNLOCK.

So, here's my first blind attempt at fixing these. Too tired to think
much more about it. Sparc's configurable cache coherency drives me
nuts. Linux apparently switched somewhere in 2011 from RMO (relaxed
memory order) to TSO (total store order), solaris always used TSO, but
the BSDs don't. Man.

Accordingly there's a somewhat ugly thingy attached. I don't think this
is really ready, but it's what I can come up today.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
0001-Fix-spinlock-implementations-for-some-sparc-and-arm-.patch text/x-patch 4.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2014-06-30 23:24:24 Re: bad estimation together with large work_mem generates terrible slow hash joins
Previous Message Fujii Masao 2014-06-30 22:18:39 Re: WAL format and API changes (9.5)