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

19

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?

Chad Harrison
źródło
4
Na przykład QNX działa w czasie rzeczywistym.
new123456

Odpowiedzi:

21

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ę.

Shinrai
źródło
6
Systemy operacyjne w czasie rzeczywistym są zwykle używane w bardzo dedykowanych rolach, takich jak bardzo precyzyjne systemy kontroli, w których decyzja / obliczenia / itp. Muszą zostać zakończone w bardzo wymagających ramach czasowych.
Lamar B
Czy są jakieś przykłady RTOS? Aktualizacja pytania w tym względzie.
Chad Harrison
To, co powiedział @ ta.speot.is - w artykule jest już link. Jednak trochę zmodyfikuję.
Shinrai
Nie dotarłem do końca strony Wiki ... Przepraszam, że: /
Chad Harrison
19

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).

Scott C. Wilson
źródło
10

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.

LawrenceC
źródło
Czy możesz wyjaśnić, co rozumiesz przez „x86 ma tylko 1 linię IRQ”? Ostatnim razem, gdy owijałem komputer 80186 (co prawda kilkadziesiąt lat temu), wydaje mi się, że pamiętam, że 8259 PIC ma 8 kanałów, a nominalny komputer w tym czasie miał drugi kaskadowo, w sumie 15 kanałów, nie licząc NMI?
Glenn Slayden,
Potrzebujesz PIC właśnie dlatego, że x86 ma tylko jedną linię IRQ. Ale jeśli przerwania x86 są wyłączone, PIC może tylko poczekać, aż CPU je ponownie włączy, a IIRC właśnie to robi. Inne procesory IIRC, takie jak 68000, miały 3 piny przerwań i oczekiwały zakodowanego poziomu priorytetu 0–7 bezpośrednio na samym procesorze. Chociaż teraz, gdy tak naprawdę to rozważam, być może 68000 wyłącza wszystkie przerwania po otrzymaniu jakiegokolwiek IRQ - nigdy nie zaprogramowałem 68000.
LawrenceC
Ach tak, teraz pamiętam. A IIRC „priorytetowy” aspekt układu 8259 - pozwalając na zagnieżdżoną obsługę IRQ - miał zachęcać system operacyjny do wyłączania przerwań w jak najmniejszym stopniu lub wcale, ale linie przerwań PC zostały przydzielone przypadkowo, pokonując to podejście? Tak czy inaczej, z pewnością wywołanie dowolnej znacznej ilości kodu w CLI ... STI nigdy nie było intencją.
Glenn Slayden,