Co oznacza „Windows nie jest systemem operacyjnym czasu rzeczywistego”?

Natknąłem się na aplikację o nazwie LatencyMon , która najwyraźniej monitoruje opóźnienia.

Zawsze rozumiałem, że im większe obciążenie procesora, tym mniej responsywny lub bardziej ukryty staje się system. Jednak w drugiej sekcji strony LatencyMon pierwsze zdanie mówi: „Windows nie jest systemem operacyjnym czasu rzeczywistego” (RTOS). To mnie zastanowiło. Mam na myśli, czy to coś różni się od jakiegokolwiek innego systemu operacyjnego, takiego jak Linux, Unix lub Mac OS X?

Czy są jakieś systemy operacyjne „w czasie rzeczywistym”? A może jest to jedynie program marketingowy, aby zachęcić Cię do zakupu ich produktu?

EDYTOWAĆ:

Czy są jeszcze jakieś przykłady RTOS?

Wikipedia faktycznie ma zaskakujące bogactwo informacji tutaj.

System operacyjny czasu rzeczywistego (RTOS) to system operacyjny przeznaczony do obsługi żądań aplikacji w czasie rzeczywistym.

Kluczową cechą RTOS jest poziom jego spójności pod względem czasu potrzebnego do zaakceptowania i wykonania zadania aplikacji; zmienność jest niestabilna. Trudny system operacyjny w czasie rzeczywistym ma mniej drgań niż miękki system operacyjny w czasie rzeczywistym. Głównym celem projektowym nie jest wysoka przepustowość, ale raczej gwarancja miękkiej lub twardej kategorii wydajności. RTOS, który zwykle lub ogólnie może dotrzymać terminu, jest miękkim systemem operacyjnym w czasie rzeczywistym, ale jeśli może deterministycznie dotrzymać terminu, jest to trudny system operacyjny w czasie rzeczywistym.

RTOS ma zaawansowany algorytm planowania. Elastyczność harmonogramu umożliwia szerszą, systemową koordynację priorytetów procesu, ale system operacyjny w czasie rzeczywistym jest częściej dedykowany wąskiemu zestawowi aplikacji. Kluczowymi czynnikami w systemie operacyjnym w czasie rzeczywistym są minimalne opóźnienie przerwania i minimalne opóźnienie przełączania wątków; system operacyjny w czasie rzeczywistym jest bardziej ceniony za to, jak szybko lub jak przewidywalnie może zareagować, niż za ilość pracy, jaką może wykonać w danym okresie.

Jest to coś, co robi bardzo niewiele systemów operacyjnych, ponieważ w przypadku wielu obciążeń jest po prostu mniej wydajne. Żaden z głównych systemów operacyjnych dla konsumentów nie jest teraz (lub o ile mi wiadomo, że był) w czasie rzeczywistym. Niestety oznacza to, że czasami rzeczy w środowisku innym niż czas rzeczywisty muszą siedzieć i czekać na inne rzeczy. Staje się to problemem tylko wtedy, gdy coś zwykle nie ustępuje w rozsądnym czasie.

Obecnie najbardziej znanymi, najczęściej wdrażanymi systemami operacyjnymi czasu rzeczywistego są:

LynxOS
OSE
QNX
RTLinux
VxWorks
Windows CE

Zobacz listę systemów operacyjnych w czasie rzeczywistym, aby uzyskać pełną listę.

Systemy operacyjne w czasie rzeczywistym są często używane w systemach wbudowanych, gdzie mogą być odpowiedzialne za coś takiego jak wskazówki lub monitorowanie systemu. Kluczową rzeczą, o której należy pamiętać w systemie czasu rzeczywistego (i co odróżnia go od systemu czasu rzeczywistego) jest to, że w systemie czasu rzeczywistego, jeśli odpowiedź jest spóźniona, jest błędna. Możesz łatwo zobaczyć, jak to działa, myśląc o zsumowaniu szeregu liczb w Excelu (gdzie jeśli operacja jest opóźniona, nie ma rzeczywistego wpływu) w porównaniu do włączenia hamulca w samochodzie (gdzie opóźnienie może być katastrofalne).

Zasadniczo, RTOS może zagwarantować, że może obsłużyć IRQ (żądanie przerwania) w określonym (zwykle niskim) przedziale czasowym. Standardowe systemy operacyjne nie mają takiej gwarancji.

W większości nowoczesnych systemów większość urządzeń może wygenerować przerwanie IRQ. Powoduje to, że procesor zatrzymuje (tj. Zostaje przerwany) to, co robi, i uruchamia program obsługi przerwań. Chodzi o to, że ten program serwisowy robi wszystko, czego potrzebuje urządzenie, tj. Pobiera dane z urządzenia do pamięci RAM, mówi urządzeniu, co ma robić dalej itp.

Na x86, ponieważ ma tylko 1 linię IRQ na CPU, kiedy odbiera przerwanie, dalsze przerwania są automatycznie wyłączane (z wyjątkiem NMI, RESET i SMI), dopóki CPU nie potwierdzi źródła przerwania i je ponownie włączy. Tak dobre sterowniki urządzeń w standardowym systemie Windows i386 / amd64 wykonają w tym stanie minimalne przetwarzanie, na tyle, aby można było włączyć ponownie przerwania, a następnie odroczyć pełne przetwarzanie przerwania na później (ponieważ system może technicznie obsłużyć tylko 1 przerwanie na procesor rdzeń na raz). Nie jestem pewien, ale uważam, że Linux robi to samo. Niemniej jednak nie ma twardej gwarancji na czas, w którym przerwanie zostanie obsłużone.

W przypadku większości urządzeń PC, takich jak dyski, klawiatury, karty sieciowe, jeśli wystąpi niewielkie opóźnienie w obsłudze IRQ, nic złego się nie wydarzy poza utratą wydajności. Może to stanowić większy problem w przypadku urządzeń takich jak wejście audio i wideo, w których urządzenie niczego nie buforuje, a komputer naprawdę musi nadążać za przychodzącym strumieniem danych.