Cosa significa "Windows non è un sistema operativo in tempo reale"?

Mi sono imbattuto in un'applicazione chiamata LatencyMon , che apparentemente esegue il monitoraggio della latenza.

Ho sempre capito che più un carico viene caricato sul processore, meno reattivo o più latente diventa il sistema. Tuttavia, nella seconda sezione della pagina LatencyMon, la prima frase dice "Windows non è un sistema operativo in tempo reale" (RTOS). Mi ha fatto pensare. Voglio dire, è diverso da qualsiasi altro sistema operativo come Linux, Unix o Mac OS X?

Esistono sistemi operativi "in tempo reale"? O è semplicemente uno schema di marketing per farti acquistare il loro prodotto?

MODIFICARE:

Inoltre, ci sono esempi di RTOS là fuori?

Wikipedia in realtà ha una sorprendente ricchezza di informazioni qui.

Un sistema operativo in tempo reale (RTOS) è un sistema operativo (SO) destinato a soddisfare le richieste di applicazioni in tempo reale.

Una caratteristica chiave di un RTOS è il livello della sua coerenza per quanto riguarda il tempo necessario per accettare e completare l'attività di un'applicazione; la variabilità è jitter. Un sistema operativo in tempo reale difficile ha meno jitter rispetto a un sistema operativo in tempo reale morbido. L'obiettivo principale del progetto non è la produttività elevata, ma piuttosto la garanzia di una categoria di prestazioni soft o hard. Un RTOS che può generalmente o generalmente rispettare una scadenza è un sistema operativo in tempo reale morbido, ma se è in grado di rispettare una scadenza in modo deterministico è un sistema operativo in tempo reale difficile.

Un RTOS ha un algoritmo avanzato per la pianificazione. La flessibilità dell'utilità di pianificazione consente una più ampia orchestrazione del sistema per computer delle priorità di processo, ma un sistema operativo in tempo reale è più frequentemente dedicato a un ristretto insieme di applicazioni. I fattori chiave in un sistema operativo in tempo reale sono la latenza di interruzione minima e la latenza di commutazione thread minima; un sistema operativo in tempo reale è valutato più per la velocità o la prevedibilità con cui può rispondere che per la quantità di lavoro che può eseguire in un determinato periodo di tempo.

Questo è qualcosa che fanno davvero pochi sistemi operativi, perché per molti carichi di lavoro è semplicemente meno efficiente. Nessuno dei principali sistemi operativi di consumo è ora (o per quanto ne sappia lo sia mai stato) in tempo reale. Sfortunatamente, ciò significa che a volte le cose in un ambiente non in tempo reale devono sedersi in attesa di altre cose. Questo diventa un problema solo quando qualcosa non cede in un ragionevole lasso di tempo, in generale.

Attualmente i sistemi operativi in ​​tempo reale più noti, più diffusi sono:

LynxOS
OSE
QNX
RTLinux
VxWorks
Windows CE

Consulta l' elenco dei sistemi operativi in ​​tempo reale per un elenco completo.

I sistemi operativi in ​​tempo reale sono spesso utilizzati per i sistemi embedded, dove potrebbero essere responsabili di qualcosa come guida o monitoraggio del sistema. La cosa fondamentale da ricordare su un sistema in tempo reale (e ciò che lo differenzia da un sistema non in tempo reale) è che in un sistema in tempo reale, se una risposta è in ritardo, è sbagliato. Puoi facilmente vedere come funziona pensando di aggiungere una serie di figure in Excel (dove se l'operazione è ritardata, non c'è alcun impatto reale) rispetto all'applicazione di un freno in un'auto (dove un ritardo potrebbe essere catastrofico).

Fondamentalmente, un RTOS può garantire che può servire un IRQ (richiesta di interruzione) in un periodo di tempo specifico (generalmente basso). I sistemi operativi standard non hanno tale garanzia.

Nella maggior parte dei sistemi moderni, la maggior parte dei dispositivi può generare un IRQ. Ciò provoca l'arresto (ovvero l'interruzione di) della CPU da parte della CPU e l'esecuzione di un programma di servizio di interruzione. L'idea è che questo programma di servizio fa tutto ciò di cui il dispositivo ha bisogno, ovvero estrae i dati dal dispositivo e nella RAM, dice al dispositivo cosa fare dopo, ecc.

Su x86, poiché ha solo 1 linea IRQ sulla CPU, quando riceve un interrupt, ulteriori interrupt vengono automaticamente disabilitati (tranne NMI, RESET e SMI) fino a quando la CPU non riconosce la sorgente di interrupt e li riattiva nuovamente. Quindi i buoni driver di dispositivo con i386 / amd64 standard Windows eseguiranno un'elaborazione minima in questo stato, quanto basta in modo che sia possibile riattivare gli interrupt, quindi rimandare l'elaborazione completa dell'interruzione a un momento successivo (poiché il sistema può tecnicamente servire solo 1 interruzione per CPU core alla volta). Non ne sono sicuro ma credo che Linux faccia lo stesso. Tuttavia, non vi è alcuna garanzia concreta del tempo in cui l'interrupt verrà sottoposto a manutenzione.

Per la maggior parte dei dispositivi PC, come dischi, tastiere, schede NIC, se si verifica un leggero ritardo nella manutenzione del loro IRQ, non accadrà nulla di grave se non una perdita di prestazioni. Questo può essere più un problema per dispositivi come l'ingresso audio e video, in cui il dispositivo non esegue il buffer di nulla e il PC deve davvero tenere il passo con il flusso di dati in entrata.