Re: removing old ports and architectures

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