Re: removing old ports and architectures

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Ants Aasma <ants(at)cybertec(dot)at>
Subject: Re: removing old ports and architectures
Date: 2013-10-16 16:26:28
Message-ID: CA+TgmoYCkDar=J5YSncF3Pk+DLjOz1dtzV87bqEeVVQNsTTT2A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 15, 2013 at 8:33 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2013-10-13 16:56:12 +0200, Tom Lane wrote:
>> More to the point for this specific case, it seems like our process
>> ought to be
>> (1) select a preferably-small set of gcc atomic intrinsics that we
>> want to use.
>
> I suggest:
> * pg_atomic_load_u32(uint32 *)
> * uint32 pg_atomic_store_u32(uint32 *)

We currently assume simple assignment suffices for this.

> * uint32 pg_atomic_exchange_u32(uint32 *ptr, uint32 val)
> * bool pg_atomic_compare_exchange_u32(uint32 *ptr, uint32 *expected, uint32 newval)
> * uint32 pg_atomic_fetch_add_u32(uint32 *ptr, uint32 add)
> * uint32 pg_atomic_fetch_sub_u32(uint32 *ptr, uint32 add)
> * uint32 pg_atomic_fetch_and_u32(uint32 *ptr, uint32 add)
> * uint32 pg_atomic_fetch_or_u32(uint32 *ptr, uint32 add)

Do we really need all of those? Compare-and-swap is clearly needed,
and fetch-and-add is also very useful. I'm not sure about the rest.
Not that I necessarily object to having them, but it will be a lot
more work.

> * u64 variants of the above
> * bool pg_atomic_test_set(void *ptr)
> * void pg_atomic_clear(void *ptr)

What are the intended semantics here?

> Ontop of that we can generically implement:
> * pg_atomic_add_until_u32(uint32 *ptr, uint32 val, uint32 limit)
> * pg_atomic_(add|sub|and|or)_fetch_u32()
> * u64 variants of the above

Are these really generally needed?

> We might also want to provide a generic implementation of the math
> operations based on pg_atomic_compare_exchange() to make it easier to
> bring up a new architecture.

+1.

I have a related problem, which is that some code I'm currently
working on vis-a-vis parallelism can run lock-free on platforms with
atomic 8 bit assignment but needs a spinlock or two elsewhere. So I'd
want to use pg_atomic_store_u64(), but I'd also need a clean way to
test, at compile time, whether it's available.

More general question: how do we move the ball down the field in this
area? I'm willing to do some of the legwork, but I doubt I can do all
of it, and I really think we need to make some progress here soon, as
it seems that you and I and Ants are all running into the same
problems in slightly different ways. What's our strategy for getting
something done here?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2013-10-16 16:48:25 Turning recovery.conf into GUCs
Previous Message Oskari Saarenmaa 2013-10-16 16:02:31 [PATCH] hstore_to_json: empty hstores must return empty json objects