LibRTPI Integration (Native Support for Priority Inheritance in Wine-NSPA).

[nine7nine]

LibRTPI - Library for implementing Mutex PI Support in RT applications.

https://github.com/gratian/librtpi

I've been implementing PI support in Wine-NSPA using the above Library. Pretty much all mutex / condvar conversions are complete. It is working well on my machine...

This support will require using an RT kernel && building the 64bit and 32bit/lib32 versions of this library... Therefore I am likely to make it optional / disabled by default. For now, it's completely disabled, and I don't even give an option to build it, or add the needed patch into my userpatches.

but this will change, once I've tested it more.

[nine7nine]

Initial Steps and Tests:

1. Manually build LibRTPI on my system
2. Rebuild Wine-NSPA-8.19 (Verify build, Scripts && Patchwork)
3. Write (a script and) create a patch to convert pthread_mutex/cond and friends
4. Make sure to link against LibRTPI on my system
5. Try to build; fix any issues that come up
6. Successful Build???
7. Test. Test. Test.

A bit more tinkering and the above will be complete, more or less.

Decisions???

a. Include instructions on building LibRTPI in the repo? b. Create a librtpi PKGBUILD for Arch Linux? c. Figure out how to add it to Wine's build system directly, instead of a && b ??

At that point, I could publish a new 8.19-nspa-pi build -- before moving onto 9.x builds... That would also give me better testing, initially - As 9.x builds will likely be a whole new can of worms (I've seen breakage for people on r/linuxaudio for plugins, apps, etc... One of the reasons I've been slow to move onto it).

[nine7nine]

Well, this is still WIP but I have initial LibRTPI-based Priority Inheritance support wired up in Wine-NSPA.

As you can see above Wineserver IS using FUTEX_LOCK(/UNLOCK)_PI_PRIVATE for locking (for regular mutexes/locks). Fsync stuff is still using futex_waitv, as expected (Futex2 doesn't support PI).... And a quick grep:

$ grep -R "pi_mutex" '/home/ninez/pkgbuilds/Wine-NSPA/wine-nspa-8x-git/pkg/wine-nspa-staging-fsync-git/usr' 
grep: /home/ninez/pkgbuilds/Wine-NSPA/wine-nspa-8x-git/pkg/wine-nspa-staging-fsync-git/usr/lib/wine/x86_64-unix/winebus.so: binary file matches
grep: /home/ninez/pkgbuilds/Wine-NSPA/wine-nspa-8x-git/pkg/wine-nspa-staging-fsync-git/usr/lib/wine/x86_64-unix/ntdll.so: binary file matches
grep: /home/ninez/pkgbuilds/Wine-NSPA/wine-nspa-8x-git/pkg/wine-nspa-staging-fsync-git/usr/lib/wine/x86_64-unix/wineusb.so: binary file matches
grep: /home/ninez/pkgbuilds/Wine-NSPA/wine-nspa-8x-git/pkg/wine-nspa-staging-fsync-git/usr/lib/wine/x86_64-unix/win32u.so: binary file matches
grep: /home/ninez/pkgbuilds/Wine-NSPA/wine-nspa-8x-git/pkg/wine-nspa-staging-fsync-git/usr/bin/wineserver: binary file matches

ATM, it's not complete support:

• Wine64 only ATM (but it should be easy to fix/add 32bit support)
• I still need to deal with condvars
• I'll need to do a slight rework of my RT patch for Ntdll
• There are a few other quirks to clean up / fix up!
• A lot of testing

But this looks to be a good endeavor. AFAIK, this is going to be the first Wine Implementation with support for Priority Inheritance. ~ There's been multiple RT implementations, multiple implementations of using pipes for synchronization objects, etc -- but again, AFAIK; there's never been PI support.

Initial testing shows promise, but I'll need to finish some of the above + enable 32bit support to run some older binaries that I use (in part) for testing / measurements.

[nine7nine]

I basically have most of it working now. Well, the big parts:

32bit / 64bit support Mutex converstions (98%) Condvars conversions (100%)

So I backed up my current librtpi hacking stuff: https://github.com/nine7nine/Wine-NSPA/tree/main/librpti-stuff ... WIP, not for general use though (although it does compile).

Next, I need to resolve librtpi -- and how to handle it (?). Currently, I just manually compile it. building both 64bit and 32bit/lib32 versions (which wine picks up). But it might be better to have it in tree.

Lastly, I'll need to decide on scope of usage; as It's unlikely I want to use the big hammer approach in my script/patch.

[nine7nine]

Got 99.9% of this sorted out, aside from how to package it...

Integrating into Wine seems to be a bit of a pain, but I may be able to integrate it into Wine-TKG build scripts. However, If I am to do that -- I might as well wait until I finish rebasing on Wine-9.x ... which I plan to start working on again, especially now; with Wine-Proton 9.0 being released... Additionally, it sounds like it may be possible to get Native Access 2 working, but I think that requires a slightly newer version of Wine (and obviously, it's important to me to get that working).

All testing so far using pi_mutex/condvars in Wine-NSPA seem to be working out well... I had planned on trimming / scoping the PI support just within ntddl, server, winealsa and a few places: But as it turns out -- that seems to cause some friction/issue that negatively affected DPC Latency tests... Converting the entire source tree yields more expected results.

That said: this is still going to require a lot of testing, before being enabled by default.

[nine7nine]

updated patchwork: https://github.com/nine7nine/Wine-NSPA/blob/main/librpti-stuff/librtpi-PI_Support.mypatch

Properly handles pi_mutex_init/destroy() ... it's getting there!

This is pretty damn stable on my machine too. That is; after fixing a few issues (some unrelated to the PI support itself).

[nine7nine]

So, as mentioned here: https://github.com/nine7nine/Wine-NSPA/issues/4#issuecomment-2097164362

I'm looking at implementing a Monitor synchronization mechanism, in the hopes of replacing the FUTEX_WAIT/WAKE + epoll_wait busy-waiting in Wineserver (part of the SHMem Threads patch -- but also a problem on vanilla Wine)...

[nine7nine]

Okay, so it's been around 2 months since I started using librtpi. Overall, it has been a success - So i am going to provide an update, and lay out a path forward.

• Replacing Wine's pthread_mutex implementation with librtpi's pi_mutex implementation works fine and is very stable. It works very well.
• I had to drop trying to implement a Monitor synchronization mechanism, and instead went with a more straight-forward mutex + condvar setup in a couple of places (very similar to the other pthread cond var usage in Wine).
• librtpi simplifies Wine's pthread_mutex implementation and provides robust PI support. It also seems to reduce lock contention / CPU usage in a few cases.
• Building librtpi in Wine's tree is problematic, due to differences between Linux distributions AND librtpi isn't really shipped by many distributions.

All around this is very positive / good news... The big hiccup is how to handle librtpi and building that support... To outline this;

1. Manually build librpti for 32/64 bit. This is easy, so i can provide instructions
2. Keep librtpi support in Wine-NSPA as optional. This is technically how things are now.
3. To build librtpi support in Wine-NSPA: all that is required is building the libs, then moving 2 patches into ../wine-tkg-userpatches before building wine-NSPA

Soooo... I think what i will do is add a proper Installation page to the wiki with generic building instructions (for Arch Linux anyway), then also provide librtpi + Wine-NSPA build instructions.). While it would be nice to simply automate all of this: that seems to have some pain points. Plus, it's really not that hard to build librtpi and Wine-NSPA with that support.

TODO: Add the relevant Wiki entry

[nine7nine]

I'm going to close this issue for a couple of reasons:

• I've updated the Wiki / README about enabling this support.
• The patchwork (and related code in Wine) has evolved and matured.
• I've been using this for months now, it's been fairly stable.
• PI Mutexes are still an optional feature

Next, while I do still want to integrate this into Wine-NSPA, it's probably not going to happen for a while. Thus, I feel since it is optionally available, with instructions - I can close this issue.

Later, I can open a new issue, specifically about statically building it in by default.