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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
