Postgres Pro
Downloads
Home   >   mailing lists

Thread: Atomic Operations

Atomic Operations

From
Markus Schiltknecht
Date:
Hi,

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.

Regards

Markus

Re: Atomic Operations

From
Alvaro Herrera
Date:
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

Re: Atomic Operations

From
Tom Lane
Date:
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