Description

#7445 adds priority inheritance to RIOT. However, there is some open debate around whether the feature should be enabled or disabled by default. This issue aims to clarify.

Desired outcome

As well as making a decision on this particular issue, it would be helpful if the discussion can serve as a platform to clarify our approach, in a wider sense, to the tradeoffs involved in the decision. Also, it would be helpful if this was then captured in a project document, for example in https://github.com/RIOT-OS/RIOT/wiki/Best-Practice-for-RIOT-Programming, or elsewhere as appropriate. This would assist a shared understanding throughout the community with regards to design priorities.

Whatever the case, the outcome should be clearly documented where appropriate, perhaps in the API reference and/or starting some "real-time programming guidelines" or similar.

Summary of previous discussion

Rough consensus on the issue pointed towards enabling by default. However, there was also strong opinion towards disabling by default.

Arguments for enabling by default

• Any other industrial RTOS I've noticed that brags about this, doesn't offer it as an option, instead it just claims it does it. @travisgriggs
• The memory argument below could just as well refer to core_msg which is built-in per default. @OlegHahm
• This makes the module easier to use. It's easier to disable when the user knows they don't need it rather than debug scheduling issues. It gives a stabler platform for users who may not know/care about the issue at all. @danpetry
• Disabling features that are not always needed (e.g., IPC) seems legit since a developer will easily figure out that he needs this feature. Disabling certain properties of the kernel may become much harder to detect. @OlegHahm

Arguments for disabling by default

• Priority inheritance adds noticeable memory overheads when used. For example, the RAM requirement for a mutex rises from 4 to 8 bytes, and there was a lot of work historically in achieving such a low overhead. Enabling this per default in RIOT, where many applications don't even have need for real-time features, and what's more noone has shown a real world application where priority inheritance would have saved the day, but cannot be trivially fixed through other means, seems like simply a waste @haukepetersen @kaspar030
• Having priority inheritance as an option gives the same marketing benefits as having it enabled by default @kaspar030
• It can be bound to the "prioritized threads" module as it's an inherent issue with this @travisgriggs

Broader design questions

• Do we per default want many features in that can be disabled when optimizing for memory usage, or do we want a very slim default system and users enable the features they want to have?
• Ease of use and low memory requirements are two of our stated design goals. When they come into conflict, which takes priority?
• Is it possible to satisfy both at once, for example having "low resource" APIs/modules and "easy to use" APIs/modules alongside them which use more memory?