Requiring 32 bit atomics - Mailing list pgsql-hackers

From Thomas Munro
Subject Requiring 32 bit atomics
Date
Msg-id CA+hUKGKrOejxohUwOeUcc1uE3uykZZescXOf0SjT9-EG1yWvig@mail.gmail.com
Whole thread Raw
Responses Re: Requiring 32 bit atomics  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

We have fallback code for computers that don't have 32 bit atomic ops.
Of course all modern ISAs have 32 bit atomics, but various comments
imagine that a new architecture might be born that we don't have
support for yet, so the fallback provides a way to bring a new system
up by implementing only the spinlock operations and emulating the
rest.  This seems pretty strange to me: by the time someone brings an
SMP kernel up on a hypothetical new architecture and gets around to
porting relational databases, it's hard to imagine that the compiler
builtins and C11 atomic support wouldn't be working.

I suppose this could be considered in the spirit of recent cleanup of
obsolete code in v16.  The specific reason I'm interested is that I
have a couple of different experimental patches in development that
would like to use atomic ops from a signal handler, which is against
the law if they're emulated with spinlocks due to self-deadlock.  Not
sure if it's really a blocker, I can surely find some way to code
around the limitation (I want to collapse a lot of flags into a single
word and set them with fetch_or), but it seemed a little weird to have
to do so for such an unlikely hypothetical consideration.

(64 bit atomics are another matter, real hardware exists that doesn't
have them.)

No patch yet, just running a flame-proof flag up the poll before
investing effort...



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: Documentation for building with meson
Next
From: Andres Freund
Date:
Subject: Re: Use pg_pwritev_with_retry() instead of write() in dir_open_for_write() to avoid partial writes?