O que significa "Windows não é um sistema operacional em tempo real"?

Me deparei com um aplicativo chamado LatencyMon , que aparentemente faz monitoramento de latência.

Sempre entendi que quanto mais carga você coloca no processador, menos responsivo ou mais latente, o sistema se torna. No entanto, na segunda seção da página LatencyMon, a primeira frase diz: "O Windows não é um sistema operacional em tempo real" (RTOS). Isso me fez pensar. Quero dizer, isso é diferente de qualquer outro sistema operacional como Linux, Unix ou Mac OS X?

Existem sistemas operacionais "em tempo real"? Ou é apenas um esquema de marketing para você comprar o produto deles?

EDITAR:

Além disso, existem exemplos de RTOS por aí?

A Wikipedia, na verdade, tem uma riqueza surpreendente de informações aqui.

Um sistema operacional em tempo real (RTOS) é um sistema operacional (SO) destinado a atender solicitações de aplicativos em tempo real.

Uma característica fundamental de um RTOS é o nível de consistência referente à quantidade de tempo que leva para aceitar e concluir a tarefa de um aplicativo; a variabilidade é instável. Um sistema operacional rígido em tempo real tem menos instabilidade que um sistema operacional flexível em tempo real. O principal objetivo do projeto não é o alto rendimento, mas a garantia de uma categoria de desempenho suave ou difícil. Um RTOS que geralmente pode ou geralmente cumpre um prazo é um sistema operacional leve em tempo real, mas se ele pode cumprir um prazo deterministicamente, é um sistema operacional rígido em tempo real.

Um RTOS possui um algoritmo avançado para agendamento. A flexibilidade do agendador permite uma orquestração mais ampla do sistema de computador das prioridades do processo, mas um sistema operacional em tempo real é mais frequentemente dedicado a um conjunto restrito de aplicativos. Os principais fatores em um sistema operacional em tempo real são a latência mínima de interrupção e a latência mínima de troca de encadeamento; um sistema operacional em tempo real é mais valorizado pela rapidez ou previsibilidade de resposta do que pela quantidade de trabalho que pode realizar em um determinado período de tempo.

Isso é algo que poucos sistemas operacionais realmente fazem, porque para muitas cargas de trabalho é simplesmente menos eficiente. Nenhum dos principais sistemas operacionais para consumidores está agora (ou que eu saiba) em tempo real. Infelizmente, isso significa que, às vezes, as coisas em um ambiente não em tempo real precisam ficar esperando por outras coisas. Isso só se torna um problema quando algo não está cedendo em um período de tempo razoável, geralmente.

Atualmente, os sistemas operacionais mais conhecidos, mais amplamente implantados e em tempo real são:

LynxOS
OSE
QNX
RTLinux
VxWorks
Windows CE

Veja a lista de sistemas operacionais em tempo real para obter uma lista abrangente.

Os sistemas operacionais em tempo real são frequentemente usados ​​para sistemas embarcados, onde podem ser responsáveis ​​por algo como orientação ou monitoramento do sistema. A principal coisa a lembrar sobre um sistema em tempo real (e o que o diferencia de um sistema não em tempo real) é que, em um sistema em tempo real, se uma resposta está atrasada, está errado. Você pode ver facilmente como isso funciona pensando em somar uma série de números no Excel (onde se a operação atrasar, não houver impacto real) versus aplicar um freio em um carro (onde um atraso pode ser catastrófico).

Basicamente, um RTOS pode garantir que pode atender a um IRQ (solicitação de interrupção) em um período de tempo específico (geralmente baixo). Os sistemas operacionais padrão não têm essa garantia.

Na maioria dos sistemas modernos, a maioria dos dispositivos pode gerar um IRQ. Isso faz com que a CPU pare (ou seja, seja interrompida) o que está fazendo e execute um programa de serviço de interrupção. A idéia é que este programa de serviço faça o que o dispositivo precisar, ou seja, retire os dados do dispositivo e entre na RAM, diga ao dispositivo o que fazer em seguida, etc.

No x86, como ele possui apenas 1 linha de IRQ na CPU, quando recebe uma interrupção, outras interrupções são automaticamente desabilitadas (exceto NMI, RESET e SMI) até que a CPU reconheça a fonte de interrupção e as reative. Portanto, bons drivers de dispositivo no Windows i386 / amd64 padrão farão um processamento mínimo nesse estado, apenas o suficiente para reativar interrupções e adiar o processamento completo da interrupção até mais tarde (porque o sistema tecnicamente pode atender apenas 1 interrupção por CPU núcleo de cada vez). Não tenho certeza, mas acredito que o Linux faz o mesmo. No entanto, não há garantia garantida do tempo em que a interrupção será atendida.

Para a maioria dos dispositivos de PC, como discos, teclados, placas de rede, se houver um pequeno atraso na manutenção do IRQ, nada de ruim acontecerá além de uma perda de desempenho. Isso pode ser mais um problema para dispositivos como entrada de áudio e vídeo, onde o dispositivo não armazena nada em buffer e o PC realmente precisa acompanhar o fluxo de dados recebido.