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).
źródło
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_FIFO
planowania 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 tradycyjnenice
wartoś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
N
zadania o najwyższym priorytecie naN
komputerze z procesorem. Podjęto wiele starań, aby uniknąć problemów z priorytetową inwersją w jądrze. Gdy proces stanieA
się uruchamialny i będzie miał wyższy priorytet niż jakikolwiek inny działający procesB
,A
zostanie natychmiast wstrzymanyB
.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 .
źródło
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
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
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 .
źródło