Atomic Operations

Markus Schiltknecht wrote:

Hi Markus,

what are the assumptions PostgreSQL normally does about atomic
operations? I see sig_atomic_t is used in signal handlers. Additionally,
there is a match for a cmpxchg instruction in some solaris ports code,
but that's about what I found in the source.

Am I safe assuming that pointer assignments are atomic (on all platforms
PostgreSQL compiles on, that is)? (This is a 'practical advice' from the
GNU Libc Manual) How about other integers smaller or equal in size to
sizeof(sig_atomic_t)?

I'm asking to make sure I rely on the same guarantees in my code.

Currently we rely on TransactionId being atomic; see
GetNewTransactionId. It's defined as uint32 somewhere, so I guess you
could rely on that.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Markus Schiltknecht <markus@bluegap.ch> writes:

what are the assumptions PostgreSQL normally does about atomic
operations?

Rule of thumb: you want to touch shared memory, you use a lock.

There are a few places that violate it, but in general you'd better have
a pretty darn good reason to not use a lock.

Offhand I recall that we assume TransactionId can be stored atomically
in a couple of places where locking would be inconvenient. (This is one
of the good reasons for not wanting to widen TransactionId to 64 bits
... the assumption would then fail on some platforms.) I do not believe
we assume that pointers can be stored atomically.

regards, tom lane