Should `Mutex` and `Condvar` respect priorities? about rust HOT 9 OPEN

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.

from rust.

std does not have an API for setting the thread priority

yet. rust-lang/libs-team#195

from rust.

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.

from rust.

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.

from rust.

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.

from rust.

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

from rust.

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.

from rust.

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

from rust.

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

from rust.