Thread: Requiring 32 bit atomics
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...
Thomas Munro <thomas.munro@gmail.com> writes: > 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. Fair point. Another point you could make is that we no longer have any test coverage for machines without 32-bit atomic ops. But wait, you say, what about mamba-nee-gaur, my HPPA dinosaur? The only actual hardware support there is equivalent to TAS(); nonetheless, if you read mamba's configure report you'll see it claims to have atomic ops. I wondered if NetBSD was implementing that by using kernel calls to disable interrupts, or something equally badly-performing. Turns out they have a pretty cute workaround for it, on HPPA and a couple of other atomics-less arches they still support. They've written short sequences that have the effect of CAS and are designed to store to memory only at the end. To make them atomic, libc asks the kernel "pretty please, if you happen to notice that I've been interrupted in the PC range from here to here, would you reset the PC to the start of that before returning?". At least on HPPA, this is implemented for 8-bit, 16-bit, and 32-bit CAS and then all the other standard atomics are implemented on top of that, so that the kernel doesn't spend too much time checking for these address ranges when it takes an interrupt. Of course this only works on single-CPU machines. On multi-CPU there's a completely different implementation that I've not spent time looking at ... but I assume the performance is a lot worse. Anyway, I think the big picture here is that nowadays we could assume that the platform offers this feature. regards, tom lane
I wrote: > But wait, you say, what about mamba-nee-gaur, my HPPA dinosaur? sigh ... s/mamba/chickadee/. Got too many NetBSD machines, perhaps. regards, tom lane
Hi, On 2022-10-27 19:44:13 -0400, Tom Lane wrote: > Turns out they have a pretty cute workaround for it, on HPPA and a couple of > other atomics-less arches they still support. They've written short > sequences that have the effect of CAS and are designed to store to memory > only at the end. To make them atomic, libc asks the kernel "pretty please, > if you happen to notice that I've been interrupted in the PC range from here > to here, would you reset the PC to the start of that before returning?". That sounds roughly like restartable sequences in the linux world - a pretty cool feature. It's too bad that it's not yet available everywhere, it does make some things a lot easier [to make performant]. > Anyway, I think the big picture here is that nowadays we could > assume that the platform offers this feature. Agreed. Greetings, Andres Freund