Why? To account for a possible failure mode where [Rtl]QueryPerformanceFrequency and [Rtl]QueryPerformanceCounter are both detoured by an app/system DLL which is order sensitive to both calls.
You could say "no known apps have done that" but I don't really see what's wrong with preemptly defending against possible race situation, especially since (1) they are hard to debug, and (2) fixing it doesn't introduce extra complexity other than a stronger memory order.
That seems way too far-fetched. Neither of those functions has side effects, and they're called in either order all the time.
Any complexity like this is inherently a problem, because it causes a reader to wonder why it's there. It's not declarative. It's also not a pattern that exists anywhere else in Wine. You could use an argument like this to justify putting MemoryBarrier() literally anywhere.
As far as I can see, the only thing we need to prevent is shearing. We don't need barriers at all. Am I missing something?
Why?
https://docs.gtk.org/glib/func.atomic_int_get.html says: "This call acts as a full compiler and hardware memory barrier (before the get)." But the actual code uses __ATOMIC_SEQ_CST, which is a barrier _after_ the load (as evident in ARM assembly), so I assumed the docs had a mistake.
Thanks, that makes sense.