Re: better atomics - v0.2

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>, 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 - v0.2
Date: 2013-11-19 17:57:30
Message-ID: 20131119175730.GJ19293@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-11-19 12:43:44 -0500, Robert Haas wrote:
> > * To be useful they usually will need to be placed in memory shared between
> > * processes or threads, most frequently by embedding them in structs. Be
> > * careful to align atomic variables to their own size!
>
> What does that mean exactly?

The alignment part? A pg_atomic_flag needs to be aligned to
sizeof(pg_atomic_flag), pg_atomic_uint32,64s to their sizeof()
respectively. When embedding them inside a struct the whole struct needs
to be allocated at least at that alignment.
Not sure how to describe that concisely.

I've added wrapper functions around the implementation that test for
alignment to make sure it's easy to spot such mistakes which could end
up having ugly results on some platforms.

> > * For several mathematical operations two variants exist: One that returns
> > * the old value before the operation was performed, and one that that returns
> > * the new value. *_fetch_<op> variants will return the old value,
> > * *_<op>_fetch the new one.
>
> Ugh. Do we really need this much complexity?

Well, based on my experience it's really what you need when writing code
using it. The _<op>_fetch variants are implemented generically using the
_fetch_<op> operations, so leaving them out wouldn't win us much. What
would you like to remove?

> > * Use higher level functionality (lwlocks, spinlocks, heavyweight locks)
> > * whenever possible. Writing correct code using these facilities is hard.
> > *
> > * For an introduction to using memory barriers within the PostgreSQL backend,
> > * see src/backend/storage/lmgr/README.barrier
>
> The extent to which these primitives themselves provide ordering
> guarantees should be documented.

Every function should have a comment to that regard, although two have
an XXX where I am not sure what we want to mandate, specifically whether
pg_atomic_test_set_flag() should be a full or acquire barrier and
whether pg_atomic_clear_flag should be full or release.

Greetings,

Andres Freund

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-11-19 17:58:52 Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1
Previous Message Josh Berkus 2013-11-19 17:51:28 Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1