3 ms·

> What I would really like is the ability to change defaults for all mutexes created in the program, and have everyone use the same std mutexes. Assuming you'r

> What I would really like is the ability to change defaults for all mutexes created in the program, and have everyone use the same std mutexes. Assuming you're building the whole userspace at once with something like yocto... you can just patch pthread to change the default to PTHREAD_PRIO_INHERIT and silently ignore attempts to set it to PTHREAD_PRIO_NONE. It's a little evil though. > By the way: rwlocks are often a bad idea +1

i_am_a_peasant 8mo ago
i think both you guys have the same job as me lol
VorpalWay 8mo ago
That is a great terrible idea (I really have to think a bit more on that). Won't help for Rust, since the mutexes there use futex directly, so you would have to patch the standard library itself (and for futex it is more complex than just enabling a flag). Seems plausible that other libraries and language runtimes might do similar things.
- surajrmal 8mo ago
  The implementation for the rust std mutex when targeting fuchsia does implement priority inheritance by default, but the zircon kernel scheduler and futex implementation are written with priority inheritance in mind as the default approach rather than something ad hoc tacked on. Unfortunately on Linux it seems like there is a large performance tradeoff which may not be worthwhile for the common case. It does seem like it would be nice to set an env variable to change the behavior through rather than require a recompile of libstd. A lot of programs use alternatives to the std library as well like parking_lot, which is indeed a pain. Sometimes I feel like trying to use Linux for realtime is an effort in futility. The ecosystem is optimized for throughput over fairness, predictability, and latency.
  - jcalvinowens 8mo ago
    > Unfortunately on Linux it seems like there is a large performance tradeoff Implementing transitive priority inheritance is just inherently algorithmically more expensive: there's no avoiding that. > Sometimes I feel like trying to use Linux for realtime is an effort in futility. If you're not actually using an RT kernel, yeah, it's futile. But if you are, the guarantees are pretty strong... on x86 PCs, the hardware gets in the way much more than the software in my experience. There's a lot of active work upstream.
    - VorpalWay 8mo ago
      The Linux priority inheritance futexes are also fair, which adds unnecessary overhead if you only care about PI, not fairness.

i_am_a_peasant 8mo ago

i think both you guys have the same job as me lol

VorpalWay 8mo ago

That is a great terrible idea (I really have to think a bit more on that). Won't help for Rust, since the mutexes there use futex directly, so you would have to patch the standard library itself (and for futex it is more complex than just enabling a flag). Seems plausible that other libraries and language runtimes might do similar things.

surajrmal 8mo ago
The implementation for the rust std mutex when targeting fuchsia does implement priority inheritance by default, but the zircon kernel scheduler and futex implementation are written with priority inheritance in mind as the default approach rather than something ad hoc tacked on. Unfortunately on Linux it seems like there is a large performance tradeoff which may not be worthwhile for the common case. It does seem like it would be nice to set an env variable to change the behavior through rather than require a recompile of libstd. A lot of programs use alternatives to the std library as well like parking_lot, which is indeed a pain. Sometimes I feel like trying to use Linux for realtime is an effort in futility. The ecosystem is optimized for throughput over fairness, predictability, and latency.
- jcalvinowens 8mo ago
  > Unfortunately on Linux it seems like there is a large performance tradeoff Implementing transitive priority inheritance is just inherently algorithmically more expensive: there's no avoiding that. > Sometimes I feel like trying to use Linux for realtime is an effort in futility. If you're not actually using an RT kernel, yeah, it's futile. But if you are, the guarantees are pretty strong... on x86 PCs, the hardware gets in the way much more than the software in my experience. There's a lot of active work upstream.
  - VorpalWay 8mo ago
    The Linux priority inheritance futexes are also fair, which adds unnecessary overhead if you only care about PI, not fairness.