Luís Henriques wrote:
http://www-md.e-technik.uni-rostock.de/ma/gol/rtsys/articulos/YCS159.pdf
Thanks for this link. This paper teached me the right keywords to feed Google and i stumbled over this one: https://drum.umd.edu/dspace/bitstream/1903/630/1/CS-TR-3252.ps However, it seems like this "Multiprocessor Priority Ceiling Protocol" doesn't allow nested locking and thus is not applicable to -rt :-(
I would like, however, to add that telling "our OS avoids dead-locks by design" is also not enough for SIL certification -- you need to prove this,
True, but you only need to do it once for the OS and not for all applications developed on top of it, afterwards
which might be as difficult as implementing your system without these mechanisms (they tend to add high complexity to the kernel).
This depends into which level of detail the SIL certifier likes to dig :-)
BTW and just for curiosity: anyone's aware of any application running on top of a Linux kernel that has been SIL (or similar) certified? I guess that you need a fully qualified kernel for SIL, right?
IIRC, you can claim yourself that your system reaches SIL1 or SIL2. (it's a little bit like the "CE" sign). The fun starts at SIL3 and SIL4, where you get your system certified by somebody else.
To sum up: most of the priority-inversion/dead-lock avoidance mechanisms (we've been discussing PI and PC but probably there are much more...) have advantages and disadventages which are widely known and documented. The conclusion, I guess, is that no "magic" solution exists and the applications system architects will need to choose one or more (or none!) of the available mechanisms.
Agreed.
My personal opinion is that, no matter what mechanism you select, if your developing critical software you will _always_ need to perform static schedulability analysis of your system and never rely on PI or PC.
Basically agreed, however, this can be a very challenging activity for a highly dynamic system like Linux :-) regards Bernhard - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
