FUTEX2 Linux Patches Updated To Support Variable-Sized Futexes

[oiaohm]

This never happens on x86/amd64 because the definition of atomics requires that the instruction's effects have finished before the next instruction begins executing. They cannot be executed out of order. That is in part why atomics are considered expensive.

This is unfortunately the definition of atomics is not true in all real hardware x86/amd64. The out of order of atomics is the same fault that is spectre. So not microcode fixed cpu against spectre can out of order atomics first thing that lead to spectre being found was atomics playing up.

Atomic operations require flushes under the MESI protocol, which invalidates copies in other caches in MESI. Usually, programmers don't need to know details at this low level and I don't pay much attention beyond this.

Again this is what define tells you it should be. Not what AMD/Intel and other went and in fact implemented in silicon. Gen 1 and Gen 2 x86/amd64 have some serous mistakes that we have to live with for now.

--However you are right that in x86 machine code, the CPU itself will keep the order given by the compiler or assembler writer.--
Indepe that the mistake presume. They way x86 out of order execution and cache memory system to support out of order execution was implemented was not 100 percent this creates the spectre problem and that you cannot trust 2 atomics close to each other to be in the same point in the timeline.

ryao and indepe what is implement in silicon unfortunately does not always match the expected specifications.

--That's just a fucking constant. You can literally replace it with the constant itself (i.e. the damn number) and not give a shit of any SDK and compile to exactly the same code. However if you replace it with 128 manually you'll soon discover it will overlap with status codes on return because those constants are not fucking magic, but the API will fail (by design).--
Weasel that 128 comes from the Microsoft windows SDK. I forgot something why it has to be probed at runtime. Depending on what cpu you have your windows 8 on depends if you get 128 or 64. Asking for a wait for multiobjects larger than what Microsoft decided a cpu can support lands you a error code WAIT_FAILED you do not end up with overlap with status codes problem. Yes the waitformultiobject was design to be resized larger in the future. Microsoft did at windows 8 but its not for all CPUs I forgot to mention that.

Please note the example I linked weasel to was person asking the question why when they made a loop on waitformultiobjects they did not get a WAIT_FAILED at 64 instead it went past 64 and finally stopped at 128 on their system so their question was way. That page is a english translation when you read the non english comes clear there is problem here. Presume that the limit is 64 is wrong. Presuming that you always have 128 is also wrong just because you have a version of windows that could support that(yes some games that say they need X intel cpu and Y AMD cpu and newer is because they are coded for 128). Thank you for the fun Microsoft. Then you have copyprotection stuff extending this even more.

[Weasel]

Weasel that 128 comes from the Microsoft windows SDK. I forgot something why it has to be probed at runtime. Depending on what cpu you have your windows 8 on depends if you get 128 or 64. Asking for a wait for multiobjects larger than what Microsoft decided a cpu can support lands you a error code WAIT_FAILED you do not end up with overlap with status codes problem. Yes the waitformultiobject was design to be resized larger in the future. Microsoft did at windows 8 but its not for all CPUs I forgot to mention that.

A macro will evaluate to a number at compile time. In compiled code (binary), it's gone, it's just the number that's left. How does this even detect different CPUs? Macros are not evaluated at runtime, they don't even exist in compiled code. The preprocessor simply does a Search & Replace for all macros and puts there the constant before compiling the code.

So this means if you use your imaginary Windows SDK, the compiled binary will fail to work on some CPUs. Neat.

Anyway, I know you're wrong since it overlaps with the status codes. But just for kicks, can you link me the SDK where it's defined as 128? Wayback Machine works too. Because really the burden of proof is on you.

[indepe]

A macro will evaluate to a number at compile time. In compiled code (binary), it's gone, it's just the number that's left. How does this even detect different CPUs? Macros are not evaluated at runtime, they don't even exist in compiled code. The preprocessor simply does a Search & Replace for all macros and puts there the constant before compiling the code.

So this means if you use your imaginary Windows SDK, the compiled binary will fail to work on some CPUs. Neat.

Anyway, I know you're wrong since it overlaps with the status codes. But just for kicks, can you link me the SDK where it's defined as 128? Wayback Machine works too. Because really the burden of proof is on you.

The fact that it was a hypothetical definition might have been overlooked initially, unsurprisingly.... anyway, from here on out I'll just sit back and get the proverbial popcorn...