Re: [HACKERS] Atomic Operations

[Tom Lane]

Markus Schiltknecht <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Atomic Operations

[Alvaro Herrera]

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 Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate