Hi, On 2026-11-03 11:41:34 +0100, Peter Eisentraut wrote: > On 19.10.26 13:55, Andres Freund wrote: > > I don't think the volatiles moved into PMSignalData are particularly > > useful. They're precisely one of the cases where volatile is just pretending > > to do things correctly. > > > Tom, is there any reason this doesn't use barriers? I assume it's just > > because the code is "too old"? > > I played around with this a little bit. Using memory barriers here makes > for very difficult to follow code, because the interacting parts are spread > over a bunch of different functions, and so you don't get the idiomatic > > do one thing > barrier > do another thing > > code. > > If we're going to touch it, would it better to try to write this with > atomics (with barrier semantics, as appropriate)? What is the current > thinking on whether the barrier macros or atomics should be used?
I don't quite get it, tbh. If you can move to atomics, you need to do just about the same analysis, no? I think using atomics is just fine, but normally for me the analysis is about the same amount of work. Sometimes atomics are a bit simpler, sometimes barriers, but more often than not the difference is marginal. Sometimes explicit barrier use can be a bit faster on x86 (because the barriers operate on non-contended memory). Greetings, Andres Freund
