Re: better atomics

On 2013-11-06 08:15:59 -0500, Robert Haas wrote:
> > 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.

I've implemented it that way and it imo looks sensible. I dislike the
pg_atomic_init_(flag|u32|u64) calls that are forced on us by wanting to
be compatible with C11, but I think that doesn't end up being too bad.

So, attached is a very first draft of an atomics implementation. There's
lots to be done, but this is how I think it should roughly look like and
what things we should implement in the beginning.
The API should be understandable from looking at
src/include/storage/atomics.h

I haven't tested the IBM xlc, HPUX IA64 acc, Sunpro fallback at all, but
the important part is that those provide the necessary tools to
implement everything. Also, even the gcc implementation falls back to
compare_and_swap() based implementations for the operations, but that
shouldn't matter for now. I haven't looked for other compilers yet.

Questions:
* Fundamental issues with the API?
* should we split of compiler/arch specific parts of into include/ports
or such? -0.5 from me.
* should we add src/include/storage/atomics subdirectory? +0.5 from me.
* Do we really want to continue to cater to compilers not supporting
PG_USE_INLINE? I've tried to add support for them, but it does make
things considerably more #ifdef-y.
Afaik it's only HPUX's acc that has problems, and it seems to work but
generate warnings, so maybe that's ok?
* Which additional compilers do we want to support? icc (might be gcc
compatible)?

Greetings,

Andres Freund

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