Should `Mutex` and `Condvar` respect priorities?

[joboet]

std does not have an API for setting the thread priority, and doesn't currently support priority inheritance on the majority of platforms (Linux and Windows in particular). Given this, does it still make sense to provide priority inheritance on any platform, when it is not guaranteed, won't be used by default and cannot be relied upon when using external libraries without inspecting the code? Or wouldn't it make more sense to deal with all the priority stuff in a separate crate? This would then allow reducing the number of synchronization primitive implementations inside std (we could switch to the queue-based variant on quite some platforms), thus simplifying efforts like #128203.

[VorpalBlade]

I would for my day job (where we use real time Linux patches) have a use case for having priority inheritance even on Linux. That would allow using third party crates on some projects. Currently it is a massive pain to use PI since virtually nothing third party (or std) uses it (I think I have seen two crates for PI on Linux on crates.io). You basically have to roll your own everything for synchronisation.

Furthermore I expect that on some targets that are more focused on real-time (QNX for example) not having PI would annoy users. (Of course that is a tire 3 target, and I don't know if it has PI currently.)

Pethaps there could be a way to enable PI globally, like the global allocator attribute? Since Rust doesn't use pthreads mutices any more it is unfortunately not as easy as enabling the flag but would require larger implementation changes in std.

[the8472]

std does not have an API for setting the thread priority

yet. rust-lang/libs-team#195

[joboet]

I would for my day job (where we use real time Linux patches) have a use case for having priority inheritance even on Linux. That would allow using third party crates on some projects. Currently it is a massive pain to use PI since virtually nothing third party (or std) uses it (I think I have seen two crates for PI on Linux on crates.io). You basically have to roll your own everything for synchronisation.

Furthermore I expect that on some targets that are more focused on real-time (QNX for example) not having PI would annoy users. (Of course that is a tire 3 target, and I don't know if it has PI currently.)

Pethaps there could be a way to enable PI globally, like the global allocator attribute? Since Rust doesn't use pthreads mutices any more it is unfortunately not as easy as enabling the flag but would require larger implementation changes in std.

That sounds like a good candidate a build-std option. It would definitely increase the maintenance burden, though, but that needn't be a blocker. The question then still remains whether the default should be platform-dependent.

[the8472]

Isn't it generally better to have the wake queues in the kernel even when no PI is involved? E.g. on a RWLock a single FUTEX_WAKE can wake up all the waiters.

[joboet]

Definitely! I just wondered whether we really have to bother on the platforms were PI is difficult to maintain.

[joshtriplett]

We definitely want to keep using futexes on Linux, and in general we probably don't want to switch to a userspace queue on any target that has a more efficient OS mechanism. I don't think we need to guarantee PI, but we should attempt to give the kernel enough information to handle priority on targets that have built-in support for it, including Linux.

[joshtriplett]

cc @m-ou-se as the resident expert on our synchronization code.

[Amanieu]

The conclusion of the libs meeting was that In general we don't make any guarantees about thread priority since this is very OS-specific and not supported on all targets. However we should make a best effort to support PI where possible as long as this doesn't impact performance, but this is purely QoI and not an API guarantee.

[the8472]

One data point of someone wanting priority inheritance for game development: https://users.rust-lang.org/t/mutex-priority-inversion/114584?u=the8472