Re: better atomics

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>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Ants Aasma <ants(at)cybertec(dot)at>
Subject: Re: better atomics
Date: 2013-11-06 13:15:59
Message-ID: CA+Tgmoa_bit25Kfyia1oHM8KKVbg91CXs7vPc7rLwXRFgSbH7w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 5, 2013 at 10:51 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> Hi,
>
> (Coming back to this now)
>
> On 2013-10-28 21:55:22 +0100, Andres Freund wrote:
>> The list I have previously suggested was:
>>
>> * pg_atomic_load_u32(uint32 *)
>> * uint32 pg_atomic_store_u32(uint32 *)
>>
>> To be able to write code without spreading volatiles all over while
>> making it very clear that that part of the code is worthy of attention.
>>
>> * uint32 pg_atomic_exchange_u32(uint32 *ptr, uint32 val)
>> * bool pg_atomic_compare_exchange_u32(uint32 *ptr, uint32 *expected, uint32 newval)
>
> So what I've previously proposed did use plain types for the
> to-be-manipulated atomic integers. I am not sure about that anymore
> though, C11 includes support for atomic operations, but it assumes that
> the to-be-manipulated variable is of a special "atomic" type. While I am
> not propose that we try to emulate C11's API completely (basically
> impossible as it uses type agnostic functions, it also exposes too
> much), it seems to make sense to allow PG's atomics to be implemented by
> C11's.
>
> The API is described at: http://en.cppreference.com/w/c/atomic
>
> The fundamental difference to what I've suggested so far is that the
> atomic variable isn't a plain integer/type but a distinct datatype that
> can *only* be manipulated via the atomic operators. That has the nice
> property that it cannot be accidentally manipulated via plain operators.
>
> E.g. it wouldn't be
> uint32 pg_atomic_fetch_add_u32(uint32 *ptr, uint32 add_);
> but
> uint32 pg_atomic_fetch_add_u32(pg_atomic_uint32 *ptr, uint32 add_);
>
> where, for now, atomic_uint32 is something like:
> typedef struct pg_atomic_uint32
> {
> volatile uint32 value;
> } pg_atomic_uint32;
> a future C11 implementation would just typedef C11's respective atomic
> type to pg_atomic_uint32.
>
> Comments?

Sadly, I don't have a clear feeling for how well or poorly that's
going to work out.

--
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 Peter Eisentraut 2013-11-06 13:38:20 Re: git diff --check whitespace checks, gitattributes
Previous Message Robert Haas 2013-11-06 13:11:00 Re: [BUGS] BUG #8573: int4range memory consumption