Jeśli chodzi o RTOS (w systemie osadzonym), kiedy piszemy aplikację wielowątkową, myślę, że to samo dzieje się w zależności od tego, ile wątków jest wykonywanych jednocześnie.

NIE!

Jeśli tak się stanie, to nie jest to system operacyjny czasu rzeczywistego (RTOS).

Krótka odpowiedź jest taka, że ​​definicja RTOS nie ma nic wspólnego z wielozadaniowością lub priorytetem. Po prostu wszystkie zadania mają gwarancje czasowe .

Reszta tego, co uważasz za cechy systemu operacyjnego RTOS (ustalanie priorytetów, ukończenie zadań itp.) to tylko konsekwencje (lub cechy) budowy systemu, w którym zadania muszą zakończyć się w określony przedział czasu.

Wielozadaniowość w RTOS jest koncepcyjnie prostsza niż w miękkim systemie operacyjnym, ponieważ wiele skomplikowanych skrajnych przypadków jest zasadniczo niedozwolonych.

Nie jest prawdą, że zadania w systemie RTOS są automatycznie deterministyczne, ale można nałożyć znacznie ściślejsze ograniczenia dotyczące czasu i częstotliwości wykonywania zadań. RTOS zazwyczaj zapewnia twarde priorytety zadań; w dowolnym momencie uruchomione jest gotowe zadanie o najwyższym priorytecie. Autor kodu ma również całkowitą kontrolę nad tym, jaki zestaw zadań jest wykonywanych; możesz rozsądnie oczekiwać, że nie ma zadań w tle o wysokim priorytecie, które mogłyby przerwać twój kod, powiedzmy, zamienić dane na dysk, chyba że je napisałeś.

Poza tym niektóre systemy RTOS zapewniają współpracę wielozadaniową. W przeciwieństwie do wielozadaniowości z wywłaszczaniem, w przypadku wielozadaniowości opartej na współpracy zadanie będzie kontynuowane, dopóki dobrowolnie nie zrezygnuje z kontroli nad procesorem.

RTOS zwykle nie gwarantuje przepustowości , zamiast tego pozwala zagwarantować opóźnienie .

Zwykle jest to osiągane przez system priorytetowy, takie jak tutaj w FreeRTOS:

Harmonogram FreeRTOS zapewnia, że ​​zadania w stanie Gotowe lub Uruchomione będą zawsze miały przypisany czas procesora (CPU) zamiast zadań niższy priorytet, które również są w stanie gotowości. Innymi słowy, zadanie umieszczone w stanie Uruchomione ma zawsze najwyższy priorytet, które można uruchomić.

Załóżmy, że masz zadanie o priorytecie 1, które zajmuje 10 ms, aby obsłużyć zdarzenie. zadanie o priorytecie 2, które zajmuje 100 ms, aby obsłużyć inne zdarzenie, i zadanie o priorytecie 3 w tle. Jeśli spodziewasz się jednego zdarzenia o priorytecie 1 nie częściej niż co sekundę, możesz powiedzieć, że najgorszy przypadek do obsługi zdarzenia o priorytecie 2 to 10 ms + 100 ms. Zadanie o priorytecie 3 może zostać arbitralnie spowolnione przez zdarzenia, ale nie przejmujesz się - ponieważ ma niski priorytet.

Wolałbym, żeby to był komentarz, ale wymaga to zbyt wielu znaków. W każdym razie, ozgur, sądząc po pytaniach w twoich odpowiedziach na komentarze, wydaje się, że nie rozumiesz, że nie możesz po prostu powiedzieć, że mój wątek trwa tak długo i oczekuje, że magicznie zadziała w połączeniu z innymi wątkami, a wszystko to dzięki systemowi operacyjnemu. Musisz zaprojektować swoje wątki i przeanalizować je pod kątem wydajności w najgorszym przypadku. Jeśli najgorszy przypadek nie spełnia Twoich wymagań, musisz przeprojektować swoje wątki.

Więc zamiast po prostu powiedzieć, że wątek 1 zajmuje 10 ms, a wątek 2 20 ms, musisz też powiedzieć, że wątek 1 musi być wykonywany co 15 ms. wątek 2 musi być wykonywany co 40 ms. wątek 3 musi być wykonywany co 500 ms, wątek N musi być wykonywany co 1500 ms. Następnie przydzielasz czas, jak długo może trwać wykonanie każdego wątku w najgorszym przypadku. Składasz to wszystko razem, identyfikujesz najgorsze możliwe scenariusze, a następnie musisz upewnić się, że każdy wątek spełnia wymagania czasowe. Ta analiza jest również miejscem, w którym można zidentyfikować, czy niektóre wątki muszą mieć wyższy priorytet niż inne, aby spełnić wymagania czasowe.

Na przykład, uruchomiony wątek5 zostaje przerwany przez wątek 4, który zostaje przerwany przez wątek 3, który zostanie przerwany przez threadN może być jednym z najgorszych scenariuszy. Umieszczasz to wszystko na osi czasu i sprawdzasz, czy nawet w tym najgorszym przypadku każdy wątek spełnia swoje wymagania czasowe. Możesz zapewnić, że wątki ukończą ten najgorszy scenariusz w sposób deterministyczny, używając harmonogramu i priorytetów w systemie operacyjnym czasu rzeczywistego. To determinizm jest tym, co tworzy system operacyjny czasu rzeczywistego.

Jeśli nadasz wątkom ten sam priorytet, stracisz część (jeśli nie całość) tego determinizmu, ponieważ harmonogram może mieć swobodę wyboru dowolnego wątku chce biec następny.

W systemie operacyjnym takim jak Windows nie tylko nie możesz określić, kiedy będzie uruchamiany każdy wątek, ale nie możesz nawet zagwarantować, że aplikacja będzie działać w dowolnym momencie. System operacyjny może zatrzymać aplikację i uruchomić niektóre usługi w tle, kiedy tylko zechce. Innymi słowy, nie ma determinizmu. Dlatego Windows nie jest systemem operacyjnym czasu rzeczywistego. Chociaż, jeśli twoje wymagania czasowe są duże, na przykład (wątek 1 działa co 10 sekund, wątek 2 uruchamia się co 15 sekund), możesz zasadniczo traktować system Windows jak system operacyjny czasu rzeczywistego, o ile uwzględnisz błąd i mniej więcej co 10 lub 15 sekund (daj lub weź kilkaset milisekund i sporadyczne pominięte okno) jest wystarczająco dobre.

Chociaż w innych odpowiedziach stwierdzono, że w „prawdziwym świecie” Twój scenariusz nie jest możliwy, aby móc odpowiedzieć na Twoje pytanie, musimy zbudować hipotetyczny system.

Nasz system składa się z pistoletu, który strzela piłkami w stałym tempie, dwóch pudełek, które „łapią” piłki i przesuwają się o jeden krok z każdą złapaną piłką. Pistolet można przełączyć, aby strzelał do jednej ze skrzynek, ale za każdym razem traci jedną kulkę. Pierwsze pudełko będzie wymagało 1000 kroków (piłek), aby dotrzeć do końca, a pudełko 2 będzie wymagało 2000.

Scenariusz 1 (zadania jedno po drugim):
- broń strzela 1000 piłek do pudełka 1, przełącza (kosztuje 1 piłkę) i strzela 2000 piłek do pudełka 2, co daje w sumie 3001 piłek .

Scenariusz 2 (zadania " jednoczesne ”):
- pistolet strzela 5 piłkami do jednego pudełka, przełącza się i strzela 5 piłkami do drugiego pudełka, aby uzyskać wrażenie jednoczesności . Koszt zmiany to (1000/5 x 2 =) 400 kulek. Tak więc, po wystrzeleniu 2400 piłek, pudełko 1 dotrze do końca, a pudełko 2 będzie potrzebować dodatkowych 1000 piłek, aby dotrzeć do końca, co daje w sumie 3400 piłek .

Stosując te wyniki do scenariusza, Zadanie 1 i pierwsza połowa Zadania 2 zakończyłyby się po 24 ms, a druga połowa Zadania 2 zajęłaby dodatkowe 10 ms, łącznie 34 ms. To wyraźnie pokazuje, że czas wymagany do wykonania zadań wydłuża się z powodu czasu straconego na przełączanie się między zadaniami . Te wyniki są również równoważne wykonaniu Zadania 1 trwającego 12 ms i Zadania 2 22 ms.