should build, flash and run. But the test should fail, since there currently is no mechanism to boost the low priority thread to the priority of the highest waiter for the resource it has exclusive access to.

Is #7445 a solution??

Just saw there are many PR regarding this open, are those test cases covered by this PR? #7455 #9306 #7444? Would be nice to have something that covers all.

Is #7445 a solution??

Yes, only needs a rebase and adaption to the changes to core/mutex that got in since 2018.

This is alternative regarding the test case used there, but IMO this PR is preferable due to its compatibility with all boards (no Makefile.ci). It does not test for priority inversion in case of core/msg - but IMO it is sensible to separate the tests, since they cover different synchronisation mechanisms.

Where are we at here?

The infrastructure to change the priority of a running thread is now in place. So half way there. (Or actually even more, extending the mutex to make use of it is relatively simple.) I think I can PR this today.

I added the corresponding code in a new commit to this PR. It kind of makes sense to me have the fix in the corresponding test application (or rather it's cleanup) in the same PR.

Note that decoupling priority inheritance for mutex and msg makes sense, as there is a trade-off. In a use case that needs to mitigate priority inversion for shared bus accesses is not automatically affected by priority inversion via msg.

The issue of priority inversion can occur due to hardware limitations (e.g. a low prio and a high prio task needing to talk to hardware on the single I2C bus available) and for some use cases cannot be avoided. I have to admit that I didn't spent much time thinking about it, but since msg is not linked to shared hardware resource, I believe that priority inversion could be solved by carefully designing the software so that it cannot occur.

In any case, #7445 implements priority inheritance only for msg_send_receive(), not for msg_send() or msg_receive(). And even there the caller of msg_send_receive() would have to first to potentially boost the priority of the receiver to not block on sending for longer than expected, and afterwards boost the priority of the sender to not block longer than expected on receiving. So 25 % of the places where priority inheritance would be needed are actually implemented in #7445 - and given that it is stale for quite some time, I don't expect this to be fixed swiftly.

We can still add priority inheritance for msg later on, if that is indeed needed.

C++ does not like the mutex initialization macro 😕

Ah, yes. Named initializers ({ .name = 42 }) are a C++2x feature :( Let me see if I can find an initializer that both C and C++ like.

The use of fwrite() to fix output when modules are intermixing fmt and stdio lead to stack overflows in the test here now :/

I wonder if we should just provide a tiny stdio implementation and make that a default module when newlib is in use :/

I changed the mutex_t to store the pid rather than a pointer to the thread to safe a bit of RAM. Locally, the rmutex_t now fits in the ESP32's sturct __lock. Let's see if Murdock also likes it.

At least this forced me to re-run the test and notice that I had to increase the stack sizes due to #18162 being merged.

Please squash!

All green and test is still passing

Uncrustify should now also hopefully be happy

🎉

thx :)

Hmm just adding the core_mutex_priority_inheritance seems to break expose something the esp32-wroom-32 board. I am trying to investigate.