Que signifie «Windows n'est pas un système d'exploitation en temps réel»?

Je suis tombé sur une application appelée LatencyMon , qui fait apparemment la surveillance de la latence.

J'ai toujours compris que plus la charge que vous mettez sur le processeur est importante, moins le système est réactif ou latent. Cependant, dans la deuxième section de la page LatencyMon, la première phrase dit: «Windows n'est pas un système d'exploitation en temps réel» (RTOS). Cela m'a fait réfléchir. Je veux dire, est-ce différent de tout autre système d'exploitation comme Linux, Unix ou Mac OS X?

Existe-t-il des systèmes d'exploitation "en temps réel"? Ou est-ce simplement un plan de marketing pour vous faire acheter leur produit?

ÉDITER:

De plus, y a-t-il des exemples de RTOS là-bas?

Wikipédia a en fait une richesse d'informations surprenante ici.

Un système d'exploitation en temps réel (RTOS) est un système d'exploitation (OS) destiné à répondre aux demandes d'applications en temps réel.

Une caractéristique clé d'un RTOS est le niveau de sa cohérence concernant le temps qu'il faut pour accepter et terminer la tâche d'une application; la variabilité est gigue. Un système d'exploitation en temps réel dur a moins de gigue qu'un système d'exploitation en temps réel souple. Le principal objectif de conception n'est pas un débit élevé, mais plutôt une garantie d'une catégorie de performance douce ou dure. Un RTOS qui peut généralement ou généralement respecter un délai est un système d'exploitation en temps réel doux, mais s'il peut respecter un délai de manière déterministe, il s'agit d'un système d'exploitation en temps réel difficile.

Un RTOS dispose d'un algorithme avancé pour la planification. La flexibilité du planificateur permet une orchestration plus large du système informatique des priorités des processus, mais un système d'exploitation en temps réel est plus souvent dédié à un ensemble restreint d'applications. Les facteurs clés dans un système d'exploitation en temps réel sont une latence d'interruption minimale et une latence de commutation de thread minimale; un système d'exploitation en temps réel est plus apprécié pour la rapidité ou la prévisibilité de sa réponse que pour la quantité de travail qu'il peut effectuer au cours d'une période donnée.

C'est quelque chose que très peu de systèmes d'exploitation font réellement, car pour beaucoup de charges de travail, c'est tout simplement moins efficace. Aucun des principaux systèmes d'exploitation grand public n'est désormais (ou à ma connaissance ne l'a jamais été) en temps réel. Malheureusement, cela signifie que parfois, les choses dans un environnement non temps réel doivent rester assis à attendre d'autres choses. Cela ne devient un problème que lorsque quelque chose ne cède pas dans un délai raisonnable, en général.

Actuellement, les systèmes d'exploitation en temps réel les plus connus et les plus déployés sont:

LynxOS
OSE
QNX
RTLinux
VxWorks
Windows CE

Voir la liste des systèmes d'exploitation en temps réel pour une liste complète.

Les systèmes d'exploitation en temps réel sont souvent utilisés pour les systèmes embarqués, où ils peuvent être responsables de quelque chose comme le guidage ou la surveillance du système. L'essentiel à retenir sur un système en temps réel (et ce qui le différencie d'un système non en temps réel) est que dans un système en temps réel, si une réponse est en retard, c'est faux. Vous pouvez facilement voir comment cela fonctionne en pensant à additionner une série de chiffres dans Excel (où si l'opération est retardée, il n'y a pas d'impact réel) par rapport à l'application d'un frein dans une voiture (où un retard pourrait être catastrophique).

Fondamentalement, un RTOS peut garantir qu'il peut répondre à une IRQ (demande d'interruption) dans un délai spécifique (généralement faible). Les systèmes d'exploitation standard n'ont pas une telle garantie.

Dans la plupart des systèmes modernes, la plupart des appareils peuvent générer une IRQ. Cela oblige le CPU à arrêter (c'est-à-dire à interrompre) ce qu'il fait et à exécuter un programme de service d'interruption. L'idée est que ce programme de service fait tout ce dont l'appareil a besoin, c'est-à-dire récupère les données de l'appareil et dans la RAM, dit à l'appareil quoi faire ensuite, etc.

Sur x86, comme il n'a qu'une seule ligne IRQ sur le processeur, lorsqu'il reçoit une interruption, les autres interruptions sont automatiquement désactivées (à l'exception de NMI, RESET et SMI) jusqu'à ce que le processeur reconnaisse la source d'interruption et les réactive. Donc, les bons pilotes de périphériques sous Windows i386 / amd64 standard feront un traitement minimal dans cet état, juste assez pour qu'il soit OK de réactiver les interruptions, puis de reporter le traitement complet de l'interruption à plus tard (car le système ne peut techniquement entretenir qu'une seule interruption par CPU à la fois). Je ne suis pas sûr mais je crois que Linux fait de même. Néanmoins, il n’existe aucune garantie ferme quant à la durée de l’interruption.

Pour la plupart des périphériques PC, tels que les disques, les claviers, les cartes réseau, s'il y a un léger retard dans la maintenance de leur IRQ, rien de mal ne se produira autre qu'une perte de performances. Cela peut être plus problématique pour des appareils tels que l'entrée audio et vidéo, où l'appareil ne met rien en mémoire tampon et le PC a vraiment besoin de suivre le flux de données entrant.