Re: better atomics - v0.2 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: better atomics - v0.2
Date
Msg-id 20131119175730.GJ19293@alap2.anarazel.de
Whole thread Raw
In response to Re: better atomics - v0.2  (Robert Haas <robertmhaas@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1
Next
From: Andres Freund
Date:
Subject: Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1