Je n'ai pas du tout fait de travail en temps réel alors prenez ça avec un grain de sel ...
On me dit qu'il existe deux catégories de «temps réel»: en temps réel dur et en temps réel doux.
«Doux en temps réel» signifie officieusement «faites-le le plus rapidement possible». Je pense que Linux sur un processeur moderne est bon pour ce genre de chose.
«Dur en temps réel» signifie de manière informelle «faites-le dans les délais requis». La fenêtre peut être assez petite, en millisecondes ou quelque chose. Les systèmes de contrôle de vol pour les missiles de croisière ou les lanceurs de satellites semblent être l'exemple canonique. Les systèmes de contrôle des processus industriels pourraient également en avoir besoin. Le ver Stuxnet semble avoir interféré avec les systèmes qui effectuent ce type de contrôle.
Vous utiliseriez RTOS dans cette dernière situation. RTOS garantit souvent la livraison d'une interruption en moins de tant d'instructions ou d'horloge ou autre.
Une autre considération pourrait être qu'un RTOS est conçu, testé et / ou «prouvé» pour ne pas consommer d'espace de pile sans limite. Il peut vivre dans une certaine quantité minimale de mémoire, et des choses comme un "OOM Killer" n'existent pas car elles ne sont pas nécessaires. Certaines des caractéristiques les plus loufoques du début de FORTRAN proviennent de ce type d'exigence. Lorsque vous avez compilé un programme FORTRAN II, vous saviez exactement combien de pile et combien de tas il fallait, car vous ne pouviez pas recurer, et vous ne pouviez rien allouer dynamiquement.
De manière réaliste, la deuxième considération (consommation maximale de mémoire garantie) peut être plus importante dans certaines applications critiques pour la sécurité que la "latence d'interruption garantie de 0,001 seconde".
J'imagine également qu'en supprimant le processus de sélection de la feuille de vigne du support du verbiage, vous constateriez que les ingénieurs choisissent un RTOS parce que "les exigences le disent".