3 ms·

Windows gained a WaitForMultipleObjects, which Linux 5.16 (end 2021) aped with a new Futex2. https://www.phoronix.com/news/Linux-5.16-sys_futex_waitv https://ww

• gpderetta 1y ago
  Futex has nothing to do with WFMO. Futex is equivalent to keyed events. The linux equivalent of WFMO is select/poll/epoll.
  • jauntywundrkind 1y ago
    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.
    • senderista 1y ago
      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.
      • cyberax 1y ago
        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.
  • jlokier 1y ago
    Perhaps they meant to write WaitOnAddress, which is the same as a basic futex.
    • gpderetta 1y ago
      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.
      • garaetjjte 1y ago
        Keyed event is older thing, somewhat similar but lacks value comparison.
      • ape4 1y ago
        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."
        • senderista 1y ago
          Thank god there's no Linus at MSFT to pointlessly veto 64-bit futex support.
• ciconia 1y ago
  io_uring support for futexes is really nice. I used it to implement mutexes and queues for working with Ruby fibers: https://github.com/digital-fabric/uringmachine/blob/main/ext/um/um_sync.c https://github.com/digital-fabric/uringmachine/blob/main/ext...
  • Asmod4n 1y ago
    I’ve tried to write something similar for mruby, saw the 90% performance hit compared to just using callbacks and never released it as a mgem.
• adrian_b 1y ago
  Windows did not gain a WaitForMultipleObjects, it had it since the first Windows NT, more than 30 years ago. While WaitForMultipleObjects was an advantage of Windows NT over UNIX, it was nothing new. IBM PL/I had an equivalent function already in 1965, almost 30 years before Windows NT. The "wait" function of IBM PL/I was actually the model for the UNIX "wait", but the UNIX function was extremely simplified and much weaker than its model, like it was also the case with the many features inherited by UNIX from Multics. Unfortunately, many decades had to pass until the descendants of UNIX began to gain features comparable in sophistication with those of the ancestors of UNIX. However the Microsoft WaitForSingleObject and WaitForMultipleObjects did not have an efficient implementation, which is why they had to add WaitOnAddress, the equivalent of Linux futex. It is true however that the Linux futex had and still has some annoying limitations, like the size of only 32 bits of the futex value, instead of 64 bits, and the fact that it is possible to wait only on a single event. Using atomic bit operations on the futex value it is actually possible to wait on multiple events, though not in the most efficient way. However here is where the 32-bit size of the futex value becomes annoying. Therefore the work that attempts to combine the advantages of "futex" with some of the advantages of WaitForMultipleObjects is very welcome. However this does not ape Windows, but it just reimplements techniques that are much older than the Microsoft company, which were well known more than a half of century ago.
  • viega 1y ago
    That's very interesting history, thanks. I agree with Linux still only supporting 32-bit futexes is a bit baffling. The only reason the width matters is for the race condition check, but that's a huge reason. I'd want to have the option to wait on values as wide as whatever the underlying hardware supports, at least!
    • adrian_b 1y ago
      The futex width matters if you implement your own waiting on multiple events, with one bit per event. The events can be signaled with atomic bit operations.
      • 1y ago
• the8472 1y ago
  But still no futex_swap[0][1] [0] https://lore.kernel.org/all/414e292195d720c780fab2781c749df3be6566aa.camel@posk.io/ https://lore.kernel.org/all/414e292195d720c780fab2781c749df3... [1] https://blog.linuxplumbersconf.org/2013/ocw/system/presentations/1653/original/LPC%20-%20User%20Threading.pdf https://blog.linuxplumbersconf.org/2013/ocw/system/presentat...
  • oasisaimlessly 1y ago
    A very sad state of affairs :( I want fibers that I can introspect in gdb!