On Wed, Apr 13, 2022 at 10:19 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Meh. I agree that it seems unlikely that anyone will come out with a > new processor design that lacks the ability to do spinlocks or atomics. > It's substantially more likely though that someone would want those > configure switches temporarily while in the process of porting > Postgres to a new processor, so that they don't have to make > absolutely everything work before they can test anything.
It's possible. I don't think it's super-likely. If someone is introducing a new architecture, they're probably going to make getting the Linux kernel and gcc working on it a pretty high priority, and they'll probably make the gcc intrinsics work, too. But you never know. Humans are unpredictable like that. > Independently of that, I think that our interest in weird old > processors is mostly about checking our assumptions about exactly > what processor-dependent facilities look like. For example, > although I agree that spinlocks should be possible on everything > we care about supporting, I missed the stone tablet on which it is > graven that thou shalt use zero for the unlocked state of a spinlock. > The main reason I keep my old HPPA dinosaur alive is because it is > (I think) our only remaining architecture in which that isn't true, > and I think we need to keep ourselves honest about that sort of > detail. Next decade's hot new processor design might do things > differently enough that it matters that we use SpinLockInit() > not memset-to-zero. This is not academic either, as we've had > exactly such bugs in the past. Here again, I think it's definitely possible that that could happen, but I don't think it's super-likely. Nobody's really implementing spinlocks as a primitive any more; they implement atomics, and you can decide for yourself how to build spinlocks on top of that and what values you want to use. And if you did decide to provide spinlocks but not atomics for some reason, you'd probably use 0 and 1 rather than 17 and 42 just because otherwise a lot of software wouldn't work on your brand new hardware, which as a hardware manufacturer is a thing you really don't want. We can be as rigorous as we like about this sort of thing, but I bet that in 2022 there is a huge amount of code out that assumes memset(...., 0, ...) is good enough. And, like, nobody's going to be that excited about building a machine where PostgreSQL works because we've carefully avoided this assumption, but 5000 other software packages that haven't been as careful all break. > The situation for OSes is a bit different, because IMV we generally > prefer to restrict ourselves to POSIX-compliant system calls, > and to the extent we can do that all OSes look alike. The reason > that Windows is such a grade-A pain in the rear is exactly that > their POSIX compliance sucks, and yet we committed to supporting > them anyway. If some new OS that is not POSIX-compliant comes > down the pike, I think we're far more likely to decline to support > it than otherwise. Yeah. > But to tie this back to the point of the thread --- anytime we > can reasonably start to rely on POSIX behavior in newer versions > of Windows, I'm for that. Sure, makes sense. -- Robert Haas EDB: http://www.enterprisedb.com
