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

Question

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

Eu 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 seu produto?

EDITAR:

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

    

Answer 1

A Wikipedia realmente tem uma riqueza surpreendente de informações aqui.

A real-time operating system (RTOS) is an operating system (OS) intended to serve real-time application requests.

A key characteristic of an RTOS is the level of its consistency concerning the amount of time it takes to accept and complete an application's task; the variability is jitter. A hard real-time operating system has less jitter than a soft real-time operating system. The chief design goal is not high throughput, but rather a guarantee of a soft or hard performance category. An RTOS that can usually or generally meet a deadline is a soft real-time OS, but if it can meet a deadline deterministically it is a hard real-time OS.

An RTOS has an advanced algorithm for scheduling. Scheduler flexibility enables a wider, computer-system orchestration of process priorities, but a real-time OS is more frequently dedicated to a narrow set of applications. Key factors in a real-time OS are minimal interrupt latency and minimal thread switching latency; a real-time OS is valued more for how quickly or how predictably it can respond than for the amount of work it can perform in a given period of time.

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

Currently the best known, most widely deployed, real-time operating systems are:

LynxOS
OSE
QNX
RTLinux
VxWorks
Windows CE

See the list of real-time operating systems for a comprehensive list.

    

Answer 2

Sistemas operacionais em tempo real são freqüentemente usados para sistemas embarcados, onde eles podem ser responsáveis por algo como orientação ou monitoramento do sistema. A principal coisa a ser lembrada 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 estiver atrasada, está errado. Você pode ver facilmente como isso funciona pensando em adicionar uma série de figuras no Excel (onde a operação está atrasada, não há impacto real) versus aplicar um freio em um carro (onde um atraso pode ser catastrófico) .

    

Answer 3

Basicamente, um RTOS pode garantir que pode atender um IRQ (solicitação de interrupção) em um período de tempo específico (geralmente baixo). 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 ideia é que esse programa de serviço faça o que o dispositivo precisar, ou seja, obtém dados do dispositivo e da memória RAM, informa ao dispositivo o que fazer a seguir, etc.

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

Para a maioria dos dispositivos PC, como discos, teclados, NICs, se houver um pequeno atraso no atendimento de IRQ, nada de ruim acontecerá, a não ser uma perda no desempenho. Isso pode ser mais um problema para dispositivos como entrada de áudio e vídeo, em que o dispositivo não armazena nada e o PC realmente precisa acompanhar o fluxo de entrada de dados.