Perhaps they meant to write WaitOnAddress, which is the same as a basic futex.

yes, sorry, I meant WaitOnAddress. I thought they were also called keyed events (or at least that was the NT name) but I might be wrong.

Keyed event is older thing, somewhat similar but lacks value comparison.

WaitOnAddress() allows 32 or 64 bit addresses. "[in] AddressSize The size of the value, in bytes. This parameter can be 1, 2, 4, or 8."

Thank god there's no Linus at MSFT to pointlessly veto 64-bit futex support.

Maybe perhaps, but its not clear to me what makes you argue that, and it doesn't match up from what I've read. From the article:

> People often describe the futex as, "Wait on memory address". That overlooks the notification side, but it’s a much more apt name, and why Windows’ name for this API (WaitOnAddress) is superior API naming (to be fair, they did have a decade to think about the name).

The difference between an Address and an Object feels pretty abstract to me. The API surfaced otherwise feels extremely similar. So I'm not sure that there's a ton of ground to stand on for this distinction you are trying to draw. Your assertions could use some argumentation to back them up.

From the Futex2 pull requests in 5.16:

> Add a new sys_futex_waitv() syscall which allows to wait on multiple futexes. The main use case is emulating Windows' WaitForMultipleObjects which allows Wine to improve the performance of Windows Games.

There is a huge difference. The Unix equivalent of an NT kernel object is a file descriptor (or more accurately an open file object). A futex is just a 32-bit word anywhere in memory, hashed to a kernel wait queue on first use. It is much lighter-weight than a kernel file object.

NT handles are a bit more lightweight compared to file descriptors. Their values are not dense, so creating a new one doesn't require searching for the first available number.