Jakie gwarancje faktycznie zapewniają „miękkie” systemy operacyjne w czasie rzeczywistym

Myślę, że wiem, czym jest „twardy” system operacyjny w czasie rzeczywistym. Jest to system operacyjny z harmonogramem, który zawiera umowę z programistą aplikacji. Aplikacja określa termin dla każdego wniosku o przydział zasobów. Jeśli żądania terminu są wykonalne , planista gwarantuje, że każdy zasób zostanie przydzielony do wnioskującej aplikacji przed upływem terminu. Gwarancja jest wystarczająca, aby umożliwić programistom aplikacji uzasadnienie maksymalnych opóźnień i minimalnej przepustowości określonych żądań.

Wydaje mi się, że wszystkie definicje „miękkich” systemów czasu rzeczywistego są puste. Wikipedia mówi

użyteczność wyniku pogarsza się po upływie terminu, tym samym obniżając jakość obsługi systemu.

Uhhh W porządku. Według tych kryteriów Windows 95 był miękkim systemem czasu rzeczywistego, podobnie jak 3BSD, podobnie jak Linux. Wikipedia nie jest doskonałym źródłem, ale kilka następnych hitów Google nie jest dużo lepszych. Na przykład http://users.ece.cmu.edu/~koopman/des_s99/real_time/ mówi

W miękkim systemie czasu rzeczywistego tolerowane może być pogorszenie działania przy rzadko występującym obciążeniu szczytowym.

To nie jest umowa, to fantazyjny sposób na nic nie mówienie.

Jakie są przykłady prawdziwych miękkich gwarancji / umów w czasie rzeczywistym oferowanych przez prawdziwe systemy operacyjne?

Szukam odpowiedzi w formularzu:

W (nazwa systemu operacyjnego), jeśli robi to programista (co-programista-musi-zrobić), system operacyjny gwarantuje (gwarancje-system-co).

Masz rację, a Wikipedia jest tak pouczająca, jak to tylko możliwe - miękki czas rzeczywisty nie jest formalną charakterystyką, jest to ocena wartości. Innym sposobem na powiedzenie „miękkiego czasu rzeczywistego” jest „Chciałbym, żeby to był czas rzeczywisty”, a dokładniej „powinno być w czasie rzeczywistym, ale to zbyt trudne”.

Jeśli naprawdę chcesz wyrazić się w formie gwarancji, jest to gwarancja najlepszego wysiłku, a nie gwarancja określonego działania.

Lub, aby zacytować FAQ Erlang (Erlang to język programowania pierwotnie zaprojektowany do użytku w telefonii):

Co oznacza soft w czasie rzeczywistym?

Cynicy powiedzą „w zasadzie nic”.

(…) Wiele systemów telekomunikacyjnych ma mniej surowe wymagania [niż trudny w czasie rzeczywistym], na przykład mogą wymagać gwarancji statystycznej w stylu „przeszukiwanie bazy danych zajmuje mniej niż 20 ms w 97% przypadków”. Miękkie systemy czasu rzeczywistego, takie jak Erlang, dają taką gwarancję.

A to zapewnia użyteczną definicję. Miękki w czasie rzeczywistym oznacza projekt zoptymalizowany pod kątem każdego zadania, który zajmuje nie więcej niż pewną ilość czasu , zamiast zoptymalizować całkowity czas poświęcony na wykonanie wszystkich zadań. Na przykład miękki system czasu rzeczywistego miałby na celu zrealizowanie 99,9% żądań w ciągu 10 ms i przetworzenie 100 żądań na sekundę, podczas gdy nie-w czasie może dążyć do przetworzenia 200 żądań na sekundę, ale od czasu do czasu pozwala na blokowanie żądań 50ms lub więcej. Trudny w czasie rzeczywistym gwarantuje jedno żądanie co 15 ms bez względu na wszystko.

Miękki czas rzeczywisty jest wykorzystywany w aplikacjach, w których przekroczenie terminu oznacza pogorszenie jakości usług, ale nie ma krytycznego wpływu na wydajność. Multimedia i telefonia to niektóre typowe przypadki użycia. Każda klatka audio lub wideo musi zostać zrenderowana w odpowiednim czasie, w przeciwnym razie należy ją pominąć; ale przeskakiwanie kadru to nie koniec świata. Projektanci Erlang mieli podobne cele dotyczące niezawodności w innych kwestiach: zauważyli, że lepiej było, aby centrala telefoniczna bardzo rzadko przerywała połączenie, ale była absolutnie pewna, że ​​centrala jako całość będzie działać, co może, niż zawsze ryzykujesz katastrofalną porażką w próbach utrzymania połączeń za wszelką cenę.

Natomiast coś takiego jak sterowanie silnikiem wymaga, aby oprogramowanie nigdy nie przekroczyło terminu. Ma to koszty: ogólna wydajność jest zazwyczaj wolniejsza i można osiągnąć tylko stosunkowo proste zachowania. Po drugiej stronie spektrum, aplikacja do liczenia liczb zwykle dba tylko o ogólną wydajność - ważne jest to, jak szybko mnoży się macierze 1000 x 1000, a nie jak szybko oblicza się każdą kolumnę.

Linux z zestawem poprawek -rt (w czasie rzeczywistym) zapewnia harmonogram, który zapewnia interesującą gwarancję, która wydaje się być pusta. (Chociaż nie jestem pewien, w jaki sposób można faktycznie skorzystać z gwarancji).

Zasady SCHED_FIFOplanowania Linux-rt działają w następujący sposób: Użytkownik przypisuje priorytet każdemu procesowi. (Numery priorytetów dla procesów „w czasie rzeczywistym” to 0–99, a tradycyjne nicewartości uniksowe od –20 do 19 odwzorowują na priorytety od 100 do 139. („0” to „najwyższy” priorytet, a „139” to „najniższy” „priorytet.)

Gwarancją jest to, że w dowolnym momencie program planujący zaplanuje Nzadania o najwyższym priorytecie na Nkomputerze z procesorem. Podjęto wiele starań, aby uniknąć problemów z priorytetową inwersją w jądrze. Gdy proces stanie Asię uruchamialny i będzie miał wyższy priorytet niż jakikolwiek inny działający proces B, Azostanie natychmiast wstrzymany B.

Należy jednak pamiętać, że nie ma żadnych ścisłych gwarancji czasowych. Czas spędzony na dokonaniu prewencji teoretycznie może być dowolnie długi. Wydaje się również, że istnieją pewne sposoby, w których zadanie o niskim priorytecie może zainicjować wiązkę we / wy długich opóźnień. Po zakończeniu operacji we / wy procedury obsługi przerwań dla zadania o niskim priorytecie mogą przerwać zadanie o wyższym priorytecie, co jest prawdopodobnie formą odwrócenia priorytetu.

Tak więc zapewniona jest ograniczona gwarancja: jeśli istnieje jeden proces o najwyższym priorytecie, za każdym razem, gdy jest on uruchomiony, otrzyma wszystkie zasoby procesora, które system operacyjny może mu w realistyczny sposób dać. Jeśli masz dobry górny limit ilości zasobów procesora zużywanych przez proces o najwyższym priorytecie, możesz obliczyć dość dokładne oszacowanie zasobów, które będą dostępne dla procesu o drugim priorytecie i tak dalej.

Szczegółowym artykułem opisującym harmonogram w czasie rzeczywistym dla systemu Linux jest http://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler .

Aby zdefiniować „miękki czas rzeczywisty”, najłatwiej jest porównać go z „trudnym czasem rzeczywistym”.

Mówiąc swobodnie, większość ludzi domyślnie ma nieformalny model mentalny, który uznaje informacje lub wydarzenie za „w czasie rzeczywistym”

• jeśli lub w takim zakresie, w jakim jest to widoczne z opóźnieniem (opóźnieniem), które można powiązać z jego postrzeganą walutą

• tzn. W ramach czasowych, w których informacje lub zdarzenia mają dla nich zadowalającą wartość.

Istnieje wiele różnych definicji ad hoc „trudnego czasu rzeczywistego”, ale w tym modelu mentalnym trudny czas rzeczywisty jest reprezentowany przez termin „jeśli”. W szczególności, zakładając, że działania w czasie rzeczywistym (takie jak zadania) mają terminy realizacji, akceptowalnie zadowalająca wartość zdarzenia, w którym wszystkie zadania zostały ukończone, jest ograniczona do szczególnego przypadku, w którym wszystkie zadania dotrzymują swoich terminów.

Trudne systemy czasu rzeczywistego przyjmują bardzo silne założenia, że ​​wszystko w aplikacji, systemie i środowisku jest statyczne i znane a priori - np. Które zadania, że ​​są okresowe, czasy przybycia, okresy, terminy, które wygrał nie występują konflikty zasobów i ogólnie ewolucja systemu w czasie. W samolotowym układzie sterowania lotem lub samochodowym układzie hamulcowym oraz w wielu innych przypadkach założenia te można zazwyczaj spełnić, aby wszystkie terminy zostały dotrzymane.

Ten model mentalny jest celowo i bardzo użyteczny na tyle ogólny, że obejmuje zarówno twarde, jak i miękkie w czasie rzeczywistym - miękkie jest uwzględniane przez wyrażenie „do tego stopnia”. Załóżmy na przykład, że zdarzenie zakończenia zadania ma nieoptymalną, ale dopuszczalną wartość if

• nie więcej niż 10% zadań nie dotrzymuje terminów
• lub żadne zadanie nie jest więcej niż 20% spóźnione
• lub średnia opóźnienie wszystkich zadań wynosi nie więcej niż 15%
• lub maksymalna spóźnienie wśród wszystkich zadań wynosi mniej niż 10%

Są to wszystkie typowe przykłady miękkich przypadków czasu rzeczywistego w bardzo wielu aplikacjach.

Rozważ zastosowanie jednego zadania polegającego na odbiorze dziecka po szkole. To prawdopodobnie nie ma rzeczywistego terminu, ale dla ciebie i twojego dziecka jest pewna wartość oparta na tym, kiedy to wydarzenie ma miejsce. Zbyt wcześnie marnuje zasoby (takie jak twój czas), a zbyt późno ma pewną negatywną wartość, ponieważ twoje dziecko może zostać pozostawione w spokoju i potencjalnie w sposób szkodliwy (lub co najmniej niewygodne).

W przeciwieństwie do statycznego twardego przypadku specjalnego w czasie rzeczywistym, miękki w czasie rzeczywistym przyjmuje jedynie minimalne niezbędne założenia dotyczące aplikacji i systemu, a ponadto oczekuje się niepewności. Aby odebrać dziecko, musisz jechać do szkoły, a czas na zrobienie tego jest dynamiczny w zależności od pogody, warunków na drodze itp. Możesz mieć ochotę na nadmierne zaopatrzenie swojego systemu (tzn. Pozwolić na to, co masz nadzieję w najgorszym przypadku czas prowadzenia pojazdu), ale znowu marnuje się zasoby (czas i zajmowanie pojazdu rodzinnego, być może odmawiając korzystania przez innych członków rodziny).

Ten przykład może nie wydawać się kosztowny pod względem zmarnowanych zasobów, ale rozważ inne przykłady. Wszystkie wojskowe systemy walki działają w czasie rzeczywistym. Rozważmy na przykład wykonanie ataku samolotem na wrogi pojazd naziemny za pomocą pocisku kierowanego aktualizacjami jako manewru celu. Maksymalne zadowolenie z wykonania zadań aktualizacji kursu osiąga się poprzez bezpośrednie niszczycielskie uderzenie w cel. Jednak próba nadmiernego zaopatrzenia w zasoby, aby upewnić się o tym wyniku, jest zwykle o wiele za droga, a nawet niemożliwa. W takim przypadku możesz być mniej, ale wystarczająco zadowolony, jeśli pocisk trafi wystarczająco blisko celu, aby go wyłączyć.

Oczywiście scenariusze walki mają wiele możliwych dynamicznych niepewności, które muszą być uwzględnione przez zarządzanie zasobami. Miękkie systemy czasu rzeczywistego są również bardzo powszechne w wielu systemach cywilnych, takich jak automatyka przemysłowa, chociaż oczywiście systemy wojskowe są najbardziej niebezpieczne i pilne, aby osiągnąć akceptowalną satysfakcjonującą wartość.

Kluczowym elementem systemów czasu rzeczywistego jest „przewidywalność”. Trudny przypadek w czasie rzeczywistym jest zainteresowany tylko jednym szczególnym przypadkiem przewidywalności - tj. Że wszystkie zadania dotrzymają terminów, a to wydarzenie osiągnie maksymalną możliwą wartość. Ten szczególny przypadek nosi nazwę „deterministyczny”.

Istnieje spektrum przewidywalności; większość systemów czasu rzeczywistego (tj. miękkich) ma niedeterministyczną przewidywalność, na przykład czasy realizacji zadań, a zatem wartości uzyskane z tych zdarzeń. Ogólnie rzecz biorąc, przewidywalność, a co za tym idzie wartość, można ustalić tak blisko deterministycznego punktu końcowego, jak to konieczne, ale za cenę, która może być fizycznie niemożliwa lub nadmiernie droga (jak w walce lub może nawet przy odbiorze dziecka ze szkoły).

Miękki w czasie rzeczywistym wymaga specyficznego dla aplikacji wyboru modelu prawdopodobieństwa (nie powszechnego modelu częstościowego), a zatem modelu przewidywalności w celu uzasadnienia opóźnień zdarzeń i wartości wynikowych.

Wracając do powyższej listy zdarzeń, które zapewniają akceptowalną wartość, teraz możemy dodać przypadki niedeterministyczne, takie jak

• prawdopodobieństwo, że żadne zadanie nie przekroczy terminu o więcej niż 5%, jest większe niż 0,87.

We wniosku dotyczącym obrony przeciwrakietowej, biorąc pod uwagę fakt, że w walce przestępstwo zawsze ma przewagę nad obroną, który z tych dwóch scenariuszy obliczeniowych w czasie rzeczywistym preferujesz:

• ponieważ idealne zniszczenie wszystkich wrogich pocisków jest bardzo mało prawdopodobne lub niemożliwe, przydziel swoje zasoby obronne, aby zmaksymalizować prawdopodobieństwo, że jak najwięcej najbardziej groźnych (np. w oparciu o ich cele) wrogich pocisków zostanie skutecznie przechwyconych (liczy się bliskie przechwycenie, ponieważ może przenieść wrogi pocisk z kursu);

• narzekaj, że nie jest to problem obliczeniowy w czasie rzeczywistym, ponieważ jest on dynamiczny zamiast statycznego, a tradycyjne koncepcje i techniki w czasie rzeczywistym nie mają zastosowania, więc nie jesteś zainteresowany przeprowadzaniem prac badawczo-rozwojowych w czasie rzeczywistym.

Pomimo różnych nieporozumień na temat miękkiego czasu rzeczywistego w społeczności komputerowej w czasie rzeczywistym (ale nie w innych dziedzinach nie obliczeniowych), miękki czas rzeczywisty jest bardzo ogólny i potężny oraz potencjalnie bardzo złożony w porównaniu z trudnym czasem rzeczywistym.

Aby bezpośrednio odpowiedzieć na pytanie OP:

• twardy system w czasie rzeczywistym może zapewnić deterministyczne gwarancje - najczęściej że wszystkie zadania dotrzymają terminów, przerwania lub czas reakcji połączenia systemowego zawsze będzie krótszy niż x itd. - JEŻELI I TYLKO JEŚLI są bardzo silne założenia i są poprawne, że wszystko, co się liczy, jest statyczne i znane a priori (ogólnie rzecz biorąc, takie gwarancje dla twardych systemów czasu rzeczywistego są otwartym problemem badawczym, z wyjątkiem dość prostych przypadków)

• miękki system czasu rzeczywistego nie daje deterministycznych gwarancji, ma na celu zapewnienie możliwie najlepszej analitycznie określonej probabilistycznej terminowości i przewidywalności terminowości, które są wykonalne w obecnych dynamicznych okolicznościach, zgodnie z kryteriami specyficznymi dla aplikacji. Oczywiście trudny czas rzeczywisty to prosty specjalny przypadek miękkiego czasu rzeczywistego. Oczywiście analityczne niedeterministyczne zapewnienia w czasie rzeczywistym mogą być bardzo złożone, ale są obowiązkowe w najczęstszych przypadkach w czasie rzeczywistym (w tym w najbardziej niebezpiecznych przypadkach krytycznych dla bezpieczeństwa, takich jak walka), ponieważ większość przypadków jest dynamiczna, a nie statyczna.

Na mojej stronie internetowej real-time.org prowadzę szczegółową, znacznie bardziej precyzyjną dyskusję na temat czasu rzeczywistego, trudnego w czasie rzeczywistym, miękkiego w czasie rzeczywistym, przewidywalności, determinizmu i pokrewnych tematów .