Parce que globalement un noyau real-time est un peu moins performant.
Par défaut le noyau ne peut pas être interrompu par un thread même si celui-ci a une haute priorité. On considère que de toutes façons le traitement effectué par le noyau ne va pas durer longtemps.. sauf que pour du real-time ça peut quand même être trop long.
L'idée c'est donc de faire en sorte que les threads de haute priorité puissent interrompre un traitement du noyau. Les mécanismes permettant ça (implémentation des spinlocks avec des rtmutexes) coûtent un peu plus cher.
À noter aussi qu'avec un noyau real-time il faut être plus prudent. Une application qui a les privilèges pour être exécutée en haute-priorité peut bloquer le noyau si elle est mal écrite (cf [2]).
[^] # Re: Question naïve sur les noyaux RT
Posté par hsyl20 (site web personnel) . En réponse à la dépêche Éditorial sonore mars 2010. Évalué à 8.
Par défaut le noyau ne peut pas être interrompu par un thread même si celui-ci a une haute priorité. On considère que de toutes façons le traitement effectué par le noyau ne va pas durer longtemps.. sauf que pour du real-time ça peut quand même être trop long.
L'idée c'est donc de faire en sorte que les threads de haute priorité puissent interrompre un traitement du noyau. Les mécanismes permettant ça (implémentation des spinlocks avec des rtmutexes) coûtent un peu plus cher.
À noter aussi qu'avec un noyau real-time il faut être plus prudent. Une application qui a les privilèges pour être exécutée en haute-priorité peut bloquer le noyau si elle est mal écrite (cf [2]).
[1] http://rt.wiki.kernel.org/index.php/Frequently_Asked_Questio(...)
[2] http://rt.wiki.kernel.org/index.php/RT_Watchdog