projekt akademicki w Institute for Mining and Technology of New Mexico. Autor Victor Yodaiken FSMLabs komercyjna odmiana RTLinuxPro

Transkrypt

1

2 projekt akademicki w Institute for Mining and Technology of New Mexico. Autor Victor Yodaiken FSMLabs komercyjna odmiana RTLinuxPro

3 Rygorystyczny (twardy) system operacyjny czasu rzeczywistego. Jego charakterystyczną cechą jest to, że współistnieją w nim: jądro czasu rzeczywistego RTCore i jądro Linuxa.

4 Wydzielenie przetwarzania w czasie rzeczywistym. Użycie dwóch różnych jąder do różnych zadań alternatywa dla wyszukiwania i poprawiania fragmentów Linuxa, które mogą stwarzać problemy przy wykonywaniu zadań krytycznych (zadań czasu rzeczywistego). Celem było wykorzystanie zaawansowanych usług i dużej wydajności, w przypadku średnim, oferowanej przez system operacyjny ogólnego przeznaczenia z zachowaniem gwarancji terminowego wykonania zadań krytycznych.

5 Pod kontrolą RTCore uruchomione jest jądro Linuxa jako wątek o najniższym priorytecie (idle thread).

6 Programy użytkownika wykonywane w przestrzenia adresowej RTCore szeregowane przez planistę tego jądra. Zadania umieszczone są we wspólnej przestrzeni adresowej bez ochrony pamięci. Korzyści wynikające powyższego rozwiązania: szybsze przełączanie kontekstu pozbawione narzutu na zmianę rejestru bazowego jednostki zarządzającej pamięcią i czyszczenia rejestrów TLB bezpośrednie dzielenie danych bez skomplikowanej komunikacji międzyprocesowej. Wadą tego rozwiązania jest to, iż błędy w zadaniach krytycznych mogą powodować awarię całego systemu.

7 Program szeregujący ładowalny moduł jądra RTCore można stworzyć własny. Zadanie 1 T1 = 50ms, C1 = 25 ms. Zadanie 2 T2 = 100ms, C2 = 40 ms. Wykorzystanie procesora wyrażone jest wzorem: U C T

8 Domyślny planista używa statycznego doboru priorytetów algorytmem RMS, zgodnie z którym im krótszy okres zadania, tym wyższy jego priorytet. Algorytm optymalny w tym sensie, że jeśli zadanie nie jest szeregowalne (nie może być wypełnione w terminie) przez ten algorytm, to nie jest szeregowalne przez żaden algorytm używający statycznych priorytetów. Wadą tego algorytmu jest niskie ograniczenie szeregowalności %, oznacza to, że jeśli zbiór zadań wykorzystuje procesor w 70%, to być może nie wszystkie zadania zostaną wypełnione w terminie.

9 Obecnie RTLinux zawiera moduł implementujący planistę z dynamicznym przydziałem priorytetów. Im bliższy nieprzekraczalny termin wykonania, tym wyższy priorytet. Zaletą tego algorytmu jest 100% ograniczenie szeregowalności, ale wadę stanowi narzut na obliczanie priorytetów.

10 RMS ani EDF nie gwarantują terminowego wykonania zadań nieokresowych zwanych sporadycznymi tzn. pojawiających się w dowolnym czasie. Szeregowanie zadań nieokresowych odbywa się przy pomocy algorytmów: Slot Shifting i Stack Stealing

11 Wątek jądra Linuxa jest wywłaszczalny, zadania krytyczne nie mogą wywoływać jego funkcji systemowych.

12 RT-FIFO dostępne są w postaci ładowalnego modułu jądra. Podobne są do linuksowych łączy nazwanych. Zaalokowane są w przestrzeni RTCore. Zadania krytyczne mogą je tworzyć, niszczyć, czytać i pisać. Operacje odczytu i zapisu są niepodzielne i nieblokujące po stronie zadań krytycznych (rozwiązuje to problem odwróconych priorytetów). Procesy linuxa widzą kolejki jako urządzenia znakowe poprzez standardowe funkcje POSIXowe.

13 mmap( ); w wersji niekomercyjnej, shm_open( ), shm_unlink( ); w wersji komercyjnej

14 Mutexy pthread_mutex

15 Odwrócenie priorytetów (priority inversion) to sytuacja, w której zadanie wysoko-priorytetowe nie dostaje procesora, choć powinno. Scenariusz ten może przybierać różne oblicza. W najprostszym przypadku odwrócenie priorytetów spowodowane jest czekaniem przez wysoko-priorytetowe zadanie, aż zadanie o niższym priorytecie zwolni zasób. Szczęśliwie opóźnienie stąd wynikające może być wyliczone wcześniej. Gorzej jest, gdy dochodzi do tego proces średniego priorytetu, który nie potrzebuje zasobu trzymanego przez proces nisko-priorytetowy i go wywłaszcza.

16 Dziedziczenie priorytetów (priority inheritance) polega na tym, że zadanie nisko-priorytetowe otrzymuje priorytet zadania wysoko-priorytetowego w momencie, gdy to drugie rozpoczęło czekanie na zasób będący w posiadaniu pierwszego zadania i utrzymuje ten priorytet do chwili, aż zwolni zasób. Uniemożliwia to wkradnięcie się zadań średniopriorytetowych. Może jednak prowadzić do zakleszczenia, gdy zadanie dziedziczące zażąda drugiego zasobu będącego akurat w posiadaniu czekającego zadania wysokopriorytetowego.

17 Ceiling Semaphore Protocol Pułap zasobu (inaczej semafora, który broni wyłącznego dostępu do tego zasobu) to maksimum po priorytetach zadań, które mogą objąć ten zasób plus jeden. Zgodnie z protokołem CSP zadanie obejmujące zasób przyjmuje priorytet równy pułapowi tego zasobu do momentu, aż zwolni zasób. Jest to rozwinięcie pomysłu dziedziczenia priorytetów eliminujące ryzyko zakleszczenia.

18 Stack Resource Policy (SRP) Według zasad szeregowania SRP zadanie nie może zacząć się wykonywać, dopóki jego priorytet nie jest najwyższy spośród zadań aktywnych lub jego poziom wywłaszczenia nie jest większy od pułapu systemowego. Poziom wywłaszczenia zadania Ti definiuje się jako Pi = 1/Di, gdzie Di jest terminem zakończenia zadania. Używając SRP zadanie, które zaczyna się wykonywać, nie zostanie zablokowane do momentu zakończenia. Może być co najwyżej wywłaszczone przez zadania o wyższych priorytetach. Nazwa SRP wynika z faktu, że wszystkie zadania mogą używać jednego stosu do zapamiętywania parametrów wywoływanych funkcji i adresów powrotu.

19 Wirtualny mechanizm przerwań jest kluczowym elementem architektury RTLinuksa. Wszystkie przerwania sprzętowe są przechwytywane przez jądro RTCore. Jednocześnie emuluje ono kontroler przerwań na potrzeby Linuxa, który nadal działa tak, jakby docierały do niego przerwania sprzętowe. Każde nadchodzące przerwanie jest przechwytywane przez jądro RTCore. Jeśli jest dla niego zainstalowana procedura obsługi czasu rzeczywistego, to jest ona wywoływana. W przeciwnym razie, o ile nie wykonuje się żadne zadanie krytyczne, przerwanie jest przekazywane do jądra Linuksa. Samodzielne jądro Linuksa czasem blokuje przerwania (np. przy synchronizacji). RTCore pamięta ustawiony przez nie stan bitu zezwolenia na przerwania. Jeśli jądro Linuksa wyłączy przerwania, to nadchodzące dla niego przerwania są oznaczane jako oczekujące i zostaną emulowane, gdy tylko Linux je odblokuje. Dzieje się tak dzięki zamianie w kodzie jądra Linuksa instrukcji cli, sti i iret odpowiednio na makra S_CLI, S_STI, S_IRET.

20 Współistnienie procesów standardowego Linuxa i RT Linuxa. Konieczność zapewnienia komunikacji pomiędzy procesami non-rt a procesami RT. Komunikacja oparta o proste kolejki FIFO RT-FIFO. RT-FIFO: Proste bufory podobne do UNIX owych pipe ów (strumień bajtów bez narzuconej struktury). Bufor o stałym rozmiarze. Operacje czytania i pisania. Interfejs RT-FIFO od strony procesów RT jest podobny do łącz nazwanych IPC. Operacje na RT-FIFO od strony procesów RT są nieblokujące.

21 Procesy Linuxa widzą RT-FIFO jako urządzenia znakowe. Procesy Linuxa działają na RT-FIFO jak na normalnych plikach pod warunkiem, że wcześniej proces RT utworzył odpowiednie RT-FIFO. Obsługa RT-FIFO zmieniała się w zależności od wersji RT Linuxa. Na początku były to urządzenia o nazwie /dev/rtf0 do 64. Pliki należało utworzyć ręcznie z poziomu Linuxa. Obecnie mogą mieć dowolne nazwy i nie trzeba tworzyć ich z poziomu systemu Linuxa. Należy uważać przy doborze nazw RT-FIFO, gdyż jeżeli istnieje w systemie plik o danej nazwie to zostanie on zniszczony bez żadnego ostrzeżenia. RT-FIFO implementowane są w przestrzeni adresowej jądra. Pamięć na RT-FIFO musi zostać zaalokowana w wątku Linuxa. Można skompilować jądro Linuxa w ten sposób aby RT-FIFO tworzone były dynamicznie, pamięć jednak przydzielana jest statycznie. Liczba RT-FIFO jest ograniczona (można ją ustalić na poziomie kompilowania jądra).

22 plication#things_you_should_not_do_in_irqf_nodelay_co ntext RTOS_RTlinux.pdf Overview.pdf