4 ms·

Linux 6.10 to Merge Driver for Emulating Windows NT Synchronization Primitives

44 points by dralley 3y ago

dmitrygr 3y ago
Before anyone gets excited, this is just nt-semantics semaphores. This isn't a proper implementation of WaitForMultipleObjects.
- olliej 3y ago
  Is that a multi semaphore/mutex primitive? Something to try and resolve the perf and/or correctness issues you can hit when dealing with multiple locks (ie things like straight deadlocks `a.lock();b.lock()` vs `b.lock();a.lock()` vs `a.lock();b.lock()` alongside threads just using the sub locks independently)
  - dmitrygr 3y ago
    https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitformultipleobjects https://learn.microsoft.com/en-us/windows/win32/api/synchapi...
sedatk 3y ago
> set to merge the NTSYNC driver for emulating the Microsoft Windows NT synchronization primitives within the kernel for allowing better performance with Valve's Steam Play (Proton) Does that mean Proton will get faster, or is this something Proton already incorporates? If the former, very exciting for Steam Deck owners.
- bno1 3y ago
  Proton uses esync or fsync which (from what I've read) are on-par with ntsync. However, esync and fsync can't be merged into upstream wine because they can't properly emulate some quirks of NT sync objects, hence the ntsync driver.
  - 3v1n0 3y ago
    NTSync still seems to outperform any userspace fsync implementation https://github.com/Frogging-Family/wine-tkg-git/issues/936#issuecomment-2042768501 https://github.com/Frogging-Family/wine-tkg-git/issues/936#i...
- oynqr 3y ago
  Proton will already use the esync/fsync implementations of these sync primitives, which are plenty fast. This new implementation is more "correct", which helps with some edge cases.
deleted 3y ago
[deleted]
tialaramex 3y ago
Did we implement what Microsoft says these primitives do, or what they actually do ? Well over a month ago, a C++ programmer noticed that, on Windows, the std::shared_mutex doesn't work properly, it can just decide to give you an exclusive ("write") lock sometimes when you ask for the non-exclusive ("read") lock. Turns out that the root cause is in Microsoft's Windows SRWLock, an OS primitive provided with exactly the required API, except oops, that's not the API implemented. The developer explains that sure, that is the documented API but as a "performance optimisation" they decided to implement something else, and after all it wasn't noticed for years so logically this is better, shouldn't maybe the C++ programming language be redefined to mean whatever it is they wanted? Within Microsoft at least it seems this was accepted, sure, we just don't implement the feature we specified, we'll say that's a "performance optimisation". But because Microsoft are also incompetent at basic ideas like generating documentation although they "accepted" the documentation which re-imagines SRWLock as having been defined differently all along, they still haven't published it a month later...
- skissane 3y ago
  > Well over a month ago, a C++ programmer noticed that, on Windows, the std::shared_mutex doesn't work properly, https://news.ycombinator.com/item?id=39581664 https://news.ycombinator.com/item?id=39581664 for anyone who didn’t see it at the time (or wants to revisit it)
- deleted 3y ago
  [deleted]

44 points by dralley 3y ago

Before anyone gets excited, this is just nt-semantics semaphores. This isn't a proper implementation of WaitForMultipleObjects.

olliej 3y ago
Is that a multi semaphore/mutex primitive? Something to try and resolve the perf and/or correctness issues you can hit when dealing with multiple locks (ie things like straight deadlocks `a.lock();b.lock()` vs `b.lock();a.lock()` vs `a.lock();b.lock()` alongside threads just using the sub locks independently)
- dmitrygr 3y ago
  https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitformultipleobjects https://learn.microsoft.com/en-us/windows/win32/api/synchapi...

sedatk 3y ago

> set to merge the NTSYNC driver for emulating the Microsoft Windows NT synchronization primitives within the kernel for allowing better performance with Valve's Steam Play (Proton) Does that mean Proton will get faster, or is this something Proton already incorporates? If the former, very exciting for Steam Deck owners.

bno1 3y ago
Proton uses esync or fsync which (from what I've read) are on-par with ntsync. However, esync and fsync can't be merged into upstream wine because they can't properly emulate some quirks of NT sync objects, hence the ntsync driver.
- 3v1n0 3y ago
  NTSync still seems to outperform any userspace fsync implementation https://github.com/Frogging-Family/wine-tkg-git/issues/936#issuecomment-2042768501 https://github.com/Frogging-Family/wine-tkg-git/issues/936#i...
oynqr 3y ago
Proton will already use the esync/fsync implementations of these sync primitives, which are plenty fast. This new implementation is more "correct", which helps with some edge cases.

deleted 3y ago

[deleted]

tialaramex 3y ago

Did we implement what Microsoft says these primitives do, or what they actually do ? Well over a month ago, a C++ programmer noticed that, on Windows, the std::shared_mutex doesn't work properly, it can just decide to give you an exclusive ("write") lock sometimes when you ask for the non-exclusive ("read") lock. Turns out that the root cause is in Microsoft's Windows SRWLock, an OS primitive provided with exactly the required API, except oops, that's not the API implemented. The developer explains that sure, that is the documented API but as a "performance optimisation" they decided to implement something else, and after all it wasn't noticed for years so logically this is better, shouldn't maybe the C++ programming language be redefined to mean whatever it is they wanted? Within Microsoft at least it seems this was accepted, sure, we just don't implement the feature we specified, we'll say that's a "performance optimisation". But because Microsoft are also incompetent at basic ideas like generating documentation although they "accepted" the documentation which re-imagines SRWLock as having been defined differently all along, they still haven't published it a month later...

skissane 3y ago
> Well over a month ago, a C++ programmer noticed that, on Windows, the std::shared_mutex doesn't work properly, https://news.ycombinator.com/item?id=39581664 https://news.ycombinator.com/item?id=39581664 for anyone who didn’t see it at the time (or wants to revisit it)
deleted 3y ago
[deleted]