IDZ DO
IDZ DO
PRZYKŁADOWY ROZDZIAŁ
PRZYKŁADOWY ROZDZIAŁ
RTLinux system
SPIS TRE CI
SPIS TRE CI
czasu rzeczywistego
KATALOG KSIĄŻEK
KATALOG KSIĄŻEK
Autorzy: Kazimierz Lal, Tomasz Rak, Krzysztof Orkisz
KATALOG ONLINE
KATALOG ONLINE
ISBN: 83-7197-898-7
Format: B5, stron: 116
ZAMÓW DRUKOWANY KATALOG
ZAMÓW DRUKOWANY KATALOG
TWÓJ KOSZYK
TWÓJ KOSZYK
Systemy czasu rzeczywistego stanowią specyficzną, ale bardzo ważną dziedzinę
DODAJ DO KOSZYKA
DODAJ DO KOSZYKA
współczesnej informatyki. Złożono ć samego przetwarzania w czasie rzeczywistym
oraz fakt, że oprogramowanie czasu rzeczywistego jest implementowane najczę ciej
w niewidocznych, najniższych warstwach systemów informatycznych, sprawia, że te
CENNIK I INFORMACJE
CENNIK I INFORMACJE
elementy są ukryte przed przeciętnymi użytkownikami, a wiedza na ich temat jest
niewielka i trudno dostępna.
ZAMÓW INFORMACJE
ZAMÓW INFORMACJE
O NOWO CIACH
O NOWO CIACH
Typowymi i najliczniejszymi przedstawicielami systemów czasu rzeczywistego są
systemy sterowania procesów przemysłowych, często należące do klasy systemów
ZAMÓW CENNIK okre lanych jako wbudowane. Ich zadaniem jest sterowanie liniami technologicznymi,
ZAMÓW CENNIK
obrabiarkami, robotami, układami napędowymi itp. W życiu codziennym systemy te
stosowane są stosowane w nowoczesnych aparatach fotograficznych do okre lania
parametrów ekspozycji, w samochodach do sterowania bezpo rednim wtryskiem
CZYTELNIA
CZYTELNIA
paliwa oraz w osobistych komputerach kieszonkowych.
FRAGMENTY KSIĄŻEK ONLINE
FRAGMENTY KSIĄŻEK ONLINE
Książka opisuje RTLinux, darmowy system operacyjny czasu rzeczywistego oparty na
Linuksie. Nowoczesna architektura i szeroki wybór platform, na których pracuje, czyni
go interesującym dla wszystkich osób potrzebujących takiego systemu. W książce
znajdziesz opisane:
" Architekturę Linuxa i modyfikacje wprowadzone w systemie RTLinux
" Instalację i konfigurację RTLinuxa
" Tworzenie aplikacji czasu rzeczywistego
" Prosty system pomiarowy czasu rzeczywistego
Uzupełnieniem książki są dodatki opisujące dokładnie pełną listę funkcji
implementowanych przez RTLinux, a także przykłady ich praktycznego wykorzystania.
Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl
Spis treści
Wstęp ...............................................................................................5
Rozdział 1. Linux a czas rzeczywisty ..................................................................11
Jądro systemu ....................................................................................................................11
Szeregowanie procesów ....................................................................................................12
Rozdzielczość szeregowania .............................................................................................12
Wywołania systemowe......................................................................................................13
Przerwania sprzą towe........................................................................................................13
Pamią ć wirtualna...............................................................................................................13
Optymalizacja wykorzystania zasobów systemowych .....................................................14
Rozdział 2. RTLinux...........................................................................................15
Podstawowe założenia.......................................................................................................15
Architektura systemu.........................................................................................................15
Wirtualny system przerwań...............................................................................................17
Zadania czasu rzeczywistego ............................................................................................18
Szeregowanie zadań ..........................................................................................................19
Odmierzanie czasu ............................................................................................................21
Komunikacja mią dzyprocesowa .......................................................................................23
Kolejki czasu rzeczywistego.......................................................................................23
Pamią ć dzielona ..........................................................................................................24
Synchronizacja i wzajemne wykluczanie ...................................................................24
Rozdział 3. Instalacja i konfiguracja systemu RTLinux ........................................27
Pakiet.................................................................................................................................27
Historia........................................................................................................................27
Autorzy .......................................................................................................................28
Licencja.......................................................................................................................29
Zawartość....................................................................................................................30
Mini-RTL....................................................................................................................31
Przebieg instalacji .............................................................................................................32
Wybór dystrybucji ......................................................................................................32
Wymagania sprzą towe ................................................................................................33
Wymagania dla środowiska programistycznego ........................................................34
yródła pakietów ..........................................................................................................36
Przebieg instalacji .......................................................................................................37
Kompilacja jądra ...............................................................................................................38
Konfiguracja i kompilacja RTLinuksa..............................................................................40
4 RTLinux system czasu rzeczywistego
Moduły czasu rzeczywistego ............................................................................................43
Uruchamianie modułów systemowych .......................................................................43
Uruchamianie modułów czasu rzeczywistego użytkownika ......................................47
Rozdział 4. Aplikacje czasu rzeczywistego ...........................................................49
Standard POSIX ................................................................................................................49
Struktura systemu RT-Linux.............................................................................................54
yródła pomocy przy programowaniu zadań czasu rzeczywistego .............................56
Kompilacja modułów ........................................................................................................57
Przykładowe problemy spotykane w aplikacjach RTLinuksa ..........................................57
Aplikacja Hello World! ...........................................................................................57
Zadania czasu rzeczywistego......................................................................................59
Kolejki czasu rzeczywistego.......................................................................................60
Obsługa przerwań systemowych.................................................................................63
Obsługa sygnałów czasu rzeczywistego w procesach Linuksa ..................................64
Zegar i funkcje konwersji czasu .................................................................................66
Pamią ć dzielona ..........................................................................................................68
Mechanizmy synchronizacji mią dzyzadaniowej ........................................................69
Rozdział 5. Prosty system pomiarowy czasu rzeczywistego.................................73
Multimetr METEX 3650CR dane techniczne..............................................................73
Komunikacja z multimetrem.............................................................................................74
Sterownik portu szeregowego ...........................................................................................75
Moduł obsługi multimetru.................................................................................................78
Uwagi końcowe.................................................................................................................85
Rozdział 6. Podsumowanie ................................................................................87
Dodatek A Pełna lista funkcji implementowanych przez system RTLinux.............89
Funkcje charakterystyczne dla systemu ............................................................................89
Podzbiór funkcji interfejsu POSIX, implementowany przez wersją 3.1...........................91
Opcjonalne funkcje POSIX zależne od konfiguracji ........................................................93
Zmienne warunkowe POSIX ............................................................................................93
Semafory POSIX...............................................................................................................93
Funkcje o ograniczonym zakresie używania ........................................................................94
Dodatek B Przykładowe programy z wykorzystaniem API systemu RTLinux .........95
Przechwytywanie przerwań...............................................................................................95
Sygnały czasu rzeczywistego w procesach Linuksa .........................................................97
Dodatek C Architektura i386, a wielozadaniowe systemy operacyjne .................99
Zarządzanie pamią cią w trybie chronionym .....................................................................99
Segmentacja ................................................................................................................99
Stronicowanie (pamią ć wirtualna) ............................................................................101
Ochrona ...........................................................................................................................102
Przerwania i obsługa wyjątków.......................................................................................103
Zarządzanie zadaniami....................................................................................................105
Bibliografia....................................................................................109
Skorowidz......................................................................................111
Rozdział 2.
RTLinux
Podstawowe założenia
Dosyć oczywistym rozwiązaniem, eliminującym wcześniej wymienione wady, wydaje
sią być modyfikacja jądra Linuksa. Taką drogą właśnie wybrali twórcy systemu KURT
(http://www.ittc.ku.edu/kurt/). Konieczne zmiany to mią dzy innymi: wprowadzenie wy-
właszczającego szeregowania procesów o stałym priorytecie, zwią kszenie rozdzielczości
szeregowania i wprowadzenie zegara wyższej rozdzielczości. Osiągnią ty kompromis
pozwolił na stworzenie systemu o łagodnych (ang. firm) ograniczeniach czasowych.
Całkowicie inną drogą do osiągnią cia cech systemu operacyjnego (ale o twardych ograni-
czeniach czasowych ang. hard real-time operating system) wybrali twórcy RTLinuksa
[2, 3]. Inspiracją w tym wypadku była architektura eksperymentalnego systemu MERT,
zbudowanego przez badaczy z Bell Labs w latach siedemdziesiątych. W zamierzeniach
system miał mieć możliwość uruchamiania zarówno aplikacji czasu rzeczywistego,
jak i zwykłych programów. Intencją projektantów systemu MERT było stworzyć nie
jeden system operacyjny, który wspiera obydwa typy przetwarzania, lecz sprawić, aby
system czasu rzeczywistego i system ogólnego przeznaczenia współistniały razem.
Twierdzili oni, że & dostępność wyrafinowanego systemu ogólnego przeznaczenia na
tym samym komputerze, co system czasu rzeczywistego, dostarcza potężnego narzędzia,
które może być wykorzystane w projektach interfejsu człowiek-maszyna dla aplikacji
czasu rzeczywistego... [1].
Architektura systemu
Bazując na ideach systemu MERT RTLinux oddziela mechanizmy systemu operacyj-
nego czasu rzeczywistego od systemu operacyjnego ogólnego zastosowania. RTLinux
działa traktując zwykłe jądro Linuksa jako zadanie pod kontrolą niewielkiego i prostego
systemu operacyjnego czasu rzeczywistego. W istocie, Linux jest zadaniem tła (ang.
idle task) dla RTLinuksa, wykonywanym jedynie wtedy, gdy żadne z zadań czasu rze-
czywistego nie ubiega sią o procesor. Z założenia zadanie Linuksa nigdy nie może zablo-
16 RTLinux system czasu rzeczywistego
kować przerwań i zapobiec wywłaszczeniu siebie. Technicznym kluczem do osiągnią cia
tego jest dodanie programowej warstwy emulującej sprzą towy mechanizm kontroli prze-
rwań. Linux nigdy nie może zablokować przerwań sprzą towych. Kiedy podejmuje taką
próbą , czą ść czasu rzeczywistego przechwytuje ten fakt, zaznacza odpowiednio i oddaje
sterowanie z powrotem do jądra Linuksa. Niezależnie od trybu, Linuksowi nie pozwala
sią na zwią kszenie opóznienia odpowiedzi na przerwanie czasu rzeczywistego. Kiedy zo-
staje zgłoszone przerwanie, jądro RTLinuksa przechwytuje je i decyduje, co z nim zrobić.
Jeśli aktualnie istnieje procedura obsługi przerwania, pochodząca z zadania czasu rze-
czywistego zostaje wywołana. Kiedy przerwanie jest obsługiwane przez Linuksa (lub
współdzielone z nim), jest oznaczane jako oczekujące. Po wykryciu próby włączenia
przerwań przez jądro Linuksa wszystkie oczekujące przerwania są emulowane i wywo-
ływane są odpowiednie procedury obsługi.
Bez znaczenia jest to, w jakim trybie działa Linux. W trybie użytkownika, w trybie
systemowym czy nawet w sekcji krytycznej jądra, RTLinux jest w stanie zareagować na
przychodzące przerwania. Techniczne aspekty dyskutowanych rozwiązań poddane są
szczegółowej analizie w podrozdziale Wirtualny system przerwań .
RTLinux separuje mechanizmy jądra czasu rzeczywistego i mechanizmy jądra zwykłego
systemu (rysunek 2.1). Tak wią c każdy z osobna może być optymalizowany niezależnie.
Jest tak zaprojektowany, że wyeliminowane są sytuacje, w których musi czekać na zwol-
nienie jakichkolwiek zasobów przez Linuksa. RTLinux nie alokuje pamią ci, nie dzieli
sekcji krytycznych ani nie synchronizuje żadnych struktur danych, z wyjątkiem sytuacji
niezbą dnych do współdziałania obydwu systemów.
Rysunek 2.1.
Architektura systemu
RTLinux [21]
Mechanizmy komunikacyjne używane do wymiany danych pomią dzy zwykłymi pro-
cesami a zadaniami czasu rzeczywistego są nieblokujące po stronie RTLinuksa. Nigdy nie
wystą puje przypadek, że zadanie czasu rzeczywistego czeka na zakolejkowanie lub po-
branie danych z kolejki.
Jedną z kluczowych zasad projektowych RTLinuksa jest, aby pozostawić go jak naj-
mniejszym i jak najprostszym. Im mniej spraw do załatwienia po stronie RTLinuksa
i im wią cej po stronie Linuksa, tym lepiej. Tak wią c startem systemu, inicjalizacją urzą-
dzeń, ładowaniem modułów, systemem plików i dynamicznym przydzielaniem zasobów
zajmuje sią zwykły system. Zadaniem RTLinuksa jest dostarczenie bezpośredniego
dostą pu do sprzą tu dla wątków czasu rzeczywistego, szeregowanie, dostarczanie me-
chanizmów odmierzania czasu i technik komunikacji mią dzyprocesowej.
Rozdział 2. f& RTLinux 17
Wirtualny system przerwań
Jądro Linuksa jest duże i monolityczne. Wielu ludzi zaangażowanych w jego rozwój czą sto
używa wyłączania przerwań w celu ochrony sekcji krytycznych. Rodzi to wspomniane
już wcześniej reperkusje. Niezbą dna korekta takiego stanu rzeczy pociągną łaby szereg
zmian w jądrze, jednak bez gwarancji wystarczająco dobrych wyników dla przetwarzania
czasu rzeczywistego.
W systemie RTLinux problem ten został rozwiązany przez Victora Yodaikena [1, 2]
poprzez zastosowanie programowej warstwy emulacji pomią dzy jądrem Linuksa a sprzą -
towym układem kontroli przerwań. Wszystkie wystąpienia makr cli, sti, iret w kodzie
zródłowym jądra zostały zastąpione makrami: S_CLI, S_STI, S_IRET. W ten sposób
emulator jest w stanie wykryć każdą próbą wyłączenia i włączenia przerwań przez jądro
Linuksa.
cli wyzerowanie znacznika IF zezwolenia na przerwania w rejestrze stanu procesora.
sti ustawienie znacznika IF zezwolenia na przerwania.
iret instrukcja powrotu z procedury obsługi przerwania.
Budową dwóch pierwszych makr przedstawia listing 2.1 (zapis w konwencji assem-
blera AT&T).
Listing 2.1. Budowa makr S_CLI oraz S_STI
Makro S_CLI powoduje, że zamiast rzeczywistego wyłączenia przerwań przez procesor
zerowana jest odpowiednia zmienna w emulatorze. Jeśli nastąpiło przerwanie i zmienna
jest ustawiona, emulator wywołuje bezpośrednio procedurą obsługi przerwania ustaloną
przez jądro Linuksa. W przeciwnym razie, gdy przerwania są wyłączone, fakt zgłoszenia
przerwania jest zapamią tywany bitowo w zmiennej, przechowującej informacje o wszyst-
kich oczekujących przerwaniach. Kiedy Linux na powrót próbuje włączyć przerwania,
wszystkie oczekujące przerwania są emulowane. Makro S_STI rzeczywiście włącza prze-
rwania i przygotowuje stos procesora jak w przypadku wywołania przerwania: odkłada
na niego flagi procesora, rejestr segmentowy jądra i adres powrotu, w tym wypadku adres
ten oznaczony jest etykietą 1:. Makro S_IRET wykonuje całą pracą emulatora przerwań
(listing 2.2).
18 RTLinux system czasu rzeczywistego
Listing 2.2. Budowa makra S_IRET
Makro najpierw zachowuje używane rejestry i ustawia rejestr segmentowy danych na
segment jądra, w celu dostą pu do zmiennych globalnych. Nastą pnie za pomocą maski
bitowej wskazującej wszystkie niezamaskowane przerwania odrzuca te przerwania, które
nie mają być wywoływane. Rejestr edx, zawierający wynik maskowania, jest przeszu-
kiwany w celu detekcji oczekujących przerwań. Ustawiony bit w omawianym rejestrze
powoduje wywołanie odpowiedniej procedury przerwania w jądrze Linuksa. Jeśli nie ma
żadnych oczekujących przerwań, wykonywany jest bezpośredni powrót z przerwania.
Instrukcja iret w procedurze obsługi przerwania, zamieniona przez RTLinuksa na
S_IRET, spowoduje odnalezienie nastą pnego oczekującego przerwania, aż do wyczer-
pania całej listy. Wszystkie potencjalne przerwania, które mogą nadejść w czasie mią dzy
poszukiwaniem oczekującego przerwania a jego wywołaniem, są opóznione w wywołaniu
co najwyżej do nastą pnej instrukcji S_STI lub S_IRET.
Zadania czasu rzeczywistego
Zadania czasu rzeczywistego są zdefiniowanymi przez użytkownika programami,
wykonywanymi pod kontrolą jądra czasu rzeczywistego. Zadania czasu rzeczywistego
wprowadzone przez RTLinuksa znacznie różnią sią od zwykłych procesów. Odmienność
ta objawia sią przede wszystkim prostotą i szybkością działania. Zadania RTLinuksa
wykonują sią we wspólnej przestrzeni adresowej (w przestrzeni jądra) z maksymalnym
poziomem uprzywilejowania i bezpośrednim dostą pem do urządzeń. Szeregowanie zadań
na tym samym poziomie ochrony przy użyciu programowego sposobu przełączania kon-
tekstu zadania daje wiele korzyści. Przełączanie kontekstu zadania jest proste i sprowadza
sią do zapamią tania i odtworzenia rejestrów procesora. Odpada narzut czasowy związany
ze zmianą trybu uprzywilejowania procesora, który podczas przełączania z trybu syste-
mowego do trybu użytkownika zajmuje kilkadziesiąt taktów procesora, podczas gdy inne
Rozdział 2. f& RTLinux 19
instrukcje poniżej dziesią ciu taktów. Niebagatelny jest również czas zyskiwany
przy zaniechaniu zmiany rejestru bazowego jednostki zarządzającej pamią cią i związanego
z tym czyszczenia rejestrów asocjacyjnych procesora, czyli unieważnienia rejestrów
związanych z TLB (ang. translation lookaside buffer). Rezygnacja z mechanizmu stro-
nicowania i ochrony pamią ci godzi niestety w integralność systemu. Każdy błąd w pro-
gramie może mieć skutek w postaci zawieszenia całego systemu. Brak ochrony pamią ci
uniemożliwia wykorzystanie prostych mechanizmów śledzenia programów i znajdowania
błą dów. Z drugiej strony jednak wspólna przestrzeń adresowa pozwala zadaniom czasu
rzeczywistego komunikować sią i dzielić dane bezpośrednio (poprzez zmienne globalne)
bez konieczności użycia złożonych technik komunikacji mią dzyprocesowej.
W odróżnieniu od zwykłych procesów Linuksa, procesy czasu rzeczywistego są tzw.
procesami lekkimi (ang. light-weight processes) lub wątkami (ang. threads) ze
wzglą du na szybkość i łatwość przełączania. Nie są jednak wątkami w rozumieniu takim,
jak w systemach operacyjnych np. Solaris czy Windows NT. Najbardziej adekwatną nazwą
dla tej kategorii procesów jest zadanie . Taka też nazwa bą dzie używana dla określenia
procesów RTLinuksa. Dodatkowo jednak użycie poją cia wątek w kontekście systemu
RTLinux w dalszej czą ści pracy również oznaczać bą dzie zadanie czasu rzeczywistego.
Mechanizmem, na którym zasadza sią cała idea procesów wykonywanych w przestrzeni
jądra, jest mechanizm modułów ładowalnych, wykorzystywany w prawie każdej nowo-
czesnej instalacji Linuksa. Technika ta, opcjonalna dla jądra Linuksa, jest krytyczna dla
działania RTLinuksa, gdyż wsparcia dla modułów ładowalnych wymagają zarówno
poszczególne moduły funkcjonalne tego systemu, jak i programy napisane przez użyt-
kownika. Moduły stanowią kawałki jądra w postaci plików obiektowych (skompilowane,
ale nieskonsolidowane), które mogą być zarówno dynamicznie linkowane i dołączane do
rezydującej w pamią ci czą ści jądra podczas działania systemu (bez konieczności czaso-
chłonnego restartu), jak i odłączane od jądra (również bez restartu).
Szeregowanie zadań
Planista (ang. scheduler) zajmujący sią szeregowaniem zadań w systemie RTLinux
stanowi odrą bny moduł. Jedynym jego zadaniem jest planowanie przydziału procesora
zadaniom według określonego algorytmu. Standardowo RTLinux używa algorytmu sze-
regowania bazującego na stałych priorytetach zadań, w którym do wykonania wybierane
jest zawsze gotowe zadanie o najwyższym priorytecie Priority-Based Rate Monotonic
Scheduling Algorithm (RMS). Jeśli istnieje kilka zadań o tym samym priorytecie, do
wykonania wybierane jest to zadanie, które w kolejce zadań zostało odnalezione jako
pierwsze. Zadaniom nie przydziela sią szczeliny czasowej , tak jak to jest w systemach
z podziałem czasu. Zakłada sią , że zadanie samo odda procesor lub zostanie wywłasz-
czone przez zadanie o wyższym priorytecie. W RTLinuksie nic nie stoi na przeszkodzie,
aby zaimplementować inny, własny algorytm planowania zadań czasu rzeczywistego.
Zmiana algorytmu szeregowania sprowadza sią do wprowadzenia zmian w funkcji po-
dejmującej decyzją : i ewentualnie w strukturze zadania, jeśli wystą puje
taka potrzeba.
20RTLinux system czasu rzeczywistego
W przeciwieństwie do innych znanych systemów operacyjnych, RTLinux nie buduje
oddzielnej kolejki procesów gotowych, które czekają na przydział procesora. Wszyst-
kie zadania tworzą jedną kolejką . Stan konkretnego zadania zapisywany jest w jego
strukturze. Od momentu, gdy RTLinux przystosowany został do działania z wykorzy-
staniem symetrycznej wieloprocesorowości, dla każdego procesora tworzona jest od-
rą bna struktura , zawierająca mią dzy innymi kolejką procesów
do wykonania na danym procesorze.
Ważniejsze pola struktury to:
wskaznik do aktualnie
wykonywanego zadania;
struktura reprezentująca zadanie
Linuksa;
wskaznik do struktury
zadania obecnie zajmującego koprocesor;
kolejka zadań czasu rzeczywistego
(jednokierunkowa lista struktur zadań czasu rzeczywistego, zadanie Linuksa
również istnieje w tej kolejce);
lista nowo utworzonych zadań,
oczekujących na dodanie do kolejki
zegar używany przez jednostką szeregującą do odmierzania
czasu;
wewną trzne flagi planisty, związane mią dzy innymi
z odmierzaniem czasu.
Struktura zadania reprezentuje wszelkie dane potrzebne do zarzą-
dzania, szeregowania i przełączania kontekstu. Zawiera ona mią dzy innymi nastą pu-
jące pola:
określa atrybuty, według których
zadanie jest szeregowane (np. priorytet);
przechowuje kontekst (rejestry) koprocesora;
pole to wskazuje, czy dane zadanie używa koprocesora, czy też nie;
jeśli zadanie nie korzysta z obliczeń zmiennoprzecinkowych, nie jest konieczne
zapamią tywanie i odtwarzanie kontekstu koprocesora;
zawiera identyfikator procesora, do którego kolejki jest przydzielone
zadanie;
pole zawiera godziną budzenia dla zadań okresowych;
dla zadań nieokresowych ma wartość HRTIME_INFINITY;
niezerowa wartość w tym polu określa odstą p czasu pomią dzy
kolejnymi wznowieniami zadania (zadanie periodyczne);
Rozdział 2. f& RTLinux 21
służy do przechowywania numerów czą ści błą dów zaistniałych
podczas działania zadania;
to pole służy jedynie do prostego sprawdzenia poprawności struktury
zadania; jego wartość różna od stałej RTL_THREAD_MAGIC oznacza, że struktura
zadania nie jest prawidłowa;
zmienna ta przechowuje sygnały sterujące stanem zadania:
RTL_SIGNAL_SUSPEND, RTL_SIGNAL_WAKEUP, RTL_SIGNAL_TIMER,
RTL_SIGNAL_CANCEL, RTL_SIGNAL_READY;
przechowuje maską aktywnych sygnałów.
Schemat algorytmu szeregowania przy użyciu pseudokodu znajduje sią na listingu 2.3.
Listing 2.3. Algorytm szeregowania implementowany przez RTLinuksa
Wartości priorytetów zadań czasu rzeczywistego można ustalać na etapie ich tworzenia
lub pózniej, w trakcie ich działania. Wyższa wartość liczbowa oznacza wyższy priorytet.
Prawidłowy zakres wartości priorytetów jest ustalany przez dwie funkcje:
zwraca maksymalną wartość priorytetu;
obecnie zwracana wartość jest stała i wynosi 1000000;
zwraca minimalną wartość priorytetu;
standardowo funkcja ta zwraca wartość 0 (zero).
Priorytet szczególnego zadania, jakim jest Linux, nie mieści sią w podanym zakresie.
Jego priorytet, jak już zostało zaznaczone wcześniej, jest najniższy i wynosi 1.
Odmierzanie czasu
Precyzyjne odmierzanie czasu jest bardzo ważne dla prawidłowego działania planisty
i zadań czasu rzeczywistego. Pewne zadania potrzebują aktywowania w określonym mo-
mencie czasu, oczekiwania na zdarzenie przez określony czas, bądz to uruchamiania co
pewien okres. Niedokładność w odmierzaniu czasu powoduje odchylenia od zaplano-
wanych terminów i jest zjawiskiem bardzo niekorzystnym.
22 RTLinux system czasu rzeczywistego
Powodem, dla którego w wią kszości uniwersalnych systemów operacyjnych istnieją
zegary o niskiej rozdzielczości, jest użycie okresowych przerwań od sprzą towego układu
zegarowego. Niska rozdzielczość jest kompromisem pomią dzy dokładnością zegara a cza-
sem spą dzanym przez system na obsłudze przerwań zegarowych. W RTLinuksie zamiast
generowania przerwań zegarowych (periodycznych) generowane są przerwania po upływie
zadanego czasu (time-out). Programowalne kontrolery czasu w komputerach klasy PC
używając takiego trybu pracy pozwalają na uzyskanie rozdzielczości czasu na pozio-
mie 1 mikrosekundy. Dodatkowo taki sposób działania zapewnia znaczne ogranicze-
nie kosztów stałych obsługi przerwań zegarowych. Korzyści z tego trybu pracy ilustruje
przykład 2.1.
W komputerach PC jest to programowalny układ czasowy Intel 8254.
Przykład 2.1. Wykorzystanie przerwania po upływie określonego czasu
Jeśli jedno zadanie musi być wykonywane co 331 jednostek czasu, a inne co 1 027 jed-
nostek (brak jest dobrego wspólnego podzielnika), to w typowej obsłudze zegara trzeba
zliczać poszczególne takty i inicjować zadanie po określonej liczbie taktów. W trybie
programowania na żądanie (ang. one-shot mode) licznik czasowy jest najpierw progra-
mowany na wygenerowanie przerwania po 331 jednostkach czasu, a nastą pnie przepro-
gramowany na nastą pne przerwanie po 691 jednostkach (zakładając, że przeprogramo-
wanie zegara trwa 5 jednostek czasu).
Niestety, jak już wspomniano, czasochłonne programowanie zegara w jednoprocesoro-
wych komputerach klasy PC ogranicza wartość minimalnego kwantu czasu do pojedyn-
czych mikrosekund. W systemach wieloprocesorowych sytuacja jest znacznie korzyst-
niejsza z powodu obecności układu regulatora czasowego wysokiej czą stotliwości.
Warto wspomnieć, że bardzo precyzyjnej techniki mierzenia upływu czasu dostarcza
rodzina procesorów Pentium. Procesory takie i zgodne z nimi posiadają wbudowany
licznik wysokiej rozdzielczości (ang. Time Stamp Counter), zerowany przy starcie
procesora i zwiększany po każdym cyklu zegara taktującego. Ten licznik może być
odczytywany przy użyciu specjalnej instrukcji RDTSC (Read Time Stamp Counter),
która zwraca 64-bitową liczbę taktów procesora. Przepełnienie tego licznika jest
praktycznie niemożliwe. Zakładając użycie procesora pracującego z częstotliwością
4 GHz, przepełnienie licznika nastąpi dopiero po ponad 146 latach nieprzerwanej
pracy komputera.
W obecnej chwili planista systemu RTLinux udostą pnia dwa tryby działania zegara:
okresowy (RTL_CLOCK_MODE_PERIODIC) i na żądanie (RTL_CLOCK_MODE_
ONESHOT). Okresowe przerwania o czą stotliwości 100 Hz są emulowane dla jądra
Linuksa. Realizowane jest to stosunkowo prosto: aby zainicjować przerwanie, ustawiany
jest odpowiedni bit w zmiennej przechowującej informacje o przerwaniach oczekujących
na obsługą . Przy nastą pnym powrocie z dowolnego przerwania (makro S_IRET) lub przy
odblokowywaniu przerwań (makro S_STI) procedura obsługi zegara w jądrze Linuksa
zostanie wywołana.
Rozdział 2. f& RTLinux 23
Komunikacja międzyprocesowa
Główną zasadą RTLinuksa jest maksymalne uproszczenie i zminimalizowanie rozmiaru
tej czą ści aplikacji, która działa w czasie rzeczywistym. Oznacza to, że pierwotna aplikacja
powinna być podzielona w taki sposób, że wszelkie operacje wymagające spełnienia
ograniczeń czasowych i bezpośredniego dostą pu do sprzą tu wykonuje zadanie czasu rze-
czywistego, zaś całą resztą działań (np. zapis danych na dysk, wizualizacja danych), które
nie są z natury ograniczone czasowo, bierze na siebie zwykły proces wykonywany w prze-
strzeni użytkownika. Konsekwencją takiej architektury jest konieczność zastosowania
dodatkowych kanałów komunikacyjnych.
Niestety, do komunikacji pomią dzy zadaniem czasu rzeczywistego i zwykłym procesem
nie można wykorzystać (całkiem bogatego zbioru) mechanizmów komunikacji mią dzypro-
cesowej, jakie oferuje standardowy Linux. Jego jądro może zostać wywłaszczone w do-
wolnym momencie. Tak wią c żadne wywołanie systemowe Linuksa zmieniające systemo-
we struktury danych nie może być bezpiecznie użyte przez zadanie czasu rzeczywistego.
RTLinux sam dostarcza wią c kilku mechanizmów komunikacji. Najważniejszymi są
kolejki czasu rzeczywistego (ang. real-time FIFOs, RT-FIFOs) i pamią ć dzielona. Do
synchronizacji procesów czasu rzeczywistego oraz wzajemnego wykluczania system ten
oferuje semafory i muteksy (omówione w podrozdziale Mechanizmy synchronizacji
mią dzyzadaniowej w rozdziale 4.).
Kolejki czasu rzeczywistego
Kolejki czasu rzeczywistego (RT-FIFO) są buforami alokowanymi w przestrzeni jądra,
które realizują algorytm pierwszy przyszedł, pierwszy obsłużony (First In First Out).
Dla odróżnienia od zwykłych kolejek, bą dących standardowym mechanizmem IPC (ang.
inter-process communication) Linuksa, kolejki czasu rzeczywistego bą dą nazywane
RT-FIFO. Mogą być odczytywane i zapisywane zarówno przez procesy linuksowe, jak
i zadania RTLinuksa. Kolejki RT-FIFO są jednokierunkowe: aplikacja nie może wyko-
rzystywać tej samej kolejki do czytania i zapisywania jednocześnie. Do uzyskania dwu-
kierunkowego połączenia należy użyć dwóch kolejek.
Kolejki RT-FIFO są urządzeniami znakowymi o numerze głównym (ang. major number)
150. Są tworzone podczas instalacji RTLinuksa i istnieją w katalogu /dev/ jako urządzenia
o nazwach /dev/rtf0, /dev/rtf1, i tak dalej, aż do /dev/rtfN, gdzie N (standardowo 64)
oznacza maksymalną liczbą kolejek czasu rzeczywistego ustaloną podczas kompilacji
systemu. Wymienione urządzenia są obsługiwane przez osobne moduły RTLinuksa.
Po stronie czasu rzeczywistego na interfejs kolejek RT-FIFO składają sią operacje:
tworzenie, niszczenie, czytanie i zapis kolejki. Odczyt i zapis są operacjami niepodziel-
nymi i nieblokującymi. Dla zwykłych procesów Linuksa kolejki RT są widoczne jako
zwykłe pliki o wspomnianych wyżej nazwach, dlatego do operowania na nich (wykony-
wania operacji we/wy na plikach) może zostać użyte standardowe API (ang. Application
Programing Interface). W najprostszym przypadku dostą p do kolejek RT-FIFO można
zrealizować przy pomocy skryptu powłoki lub polecenia jednowierszowego.
24 RTLinux system czasu rzeczywistego
Pamięć dzielona
Pamią ć dzielona może służyć do wymiany wią kszych ilości danych pomią dzy zadaniem
czasu rzeczywistego a zwykłym procesem. Jest to najszybszy sposób komunikacji pomią -
dzy zadaniami, ze wzglą du na prostotą i brak zaangażowania systemu w realizacją tej
techniki, nie uwzglą dniając oczywiście mechanizmu odwzorowywania pamią ci i prze-
chwytywania wyjątków.
Używanie pamią ci wspólnej pozwala wielu zadaniom korzystać z tych samych da-
nych. Niestety, zapis do pamią ci dzielonej wymaga postą powania według określone-
go protokołu w celu zachowania integralności danych. W przeciwieństwie do kolejek,
przy użyciu pamią ci wspólnej możliwa jest wymiana danych w postaci struktur. Jedynym
limitem rozmiaru pamią ci dzielonej jest rozmiar fizycznej pamią ci dostą pnej w systemie
komputerowym.
Synchronizacja i wzajemne wykluczanie
W każdym środowisku wielozadaniowym procesy mogą na siebie oddziaływać. W przy-
padku korzystania ze wspólnej przestrzeni adresowej współbieżny dostą p do danych dzie-
lonych może powodować ich niespójność. W celu zapewnienia wyłącznego dostą pu do
zasobu konieczne jest użycie pewnych mechanizmów wzajemnego wykluczania i syn-
chronizacji. Dla systemów czasu rzeczywistego, oprócz zachowania integralności zasobu
dzielonego i uniknią cia zakleszczeń, ważnym problemem jest minimalizacja inwersji
priorytetów.
Inwersja priorytetów oznacza fakt zajmowania zasobu dzielonego przez zadanie o niskim
priorytecie, podczas gdy w systemie istnieje zadanie o wyższym priorytecie, oczekujące
na dostą p do tego samego zasobu.
Zakleszczenie (ang. deadlock) jest sytuacją, w której zbiór procesów czeka w nieskoń-
czoność na zdarzenie, które może być spowodowane tylko przez jeden z oczekują-
cych procesów.
Przykład 2.2. Inwersja priorytetów
Rozważmy dla przykładu dwa procesy okresowe, które chcą mieć wyłączny dostą p do
pewnego logicznego zasobu. W systemie ze statycznym priorytetem zadań może dojść do
sytuacji, gdzie niskopriorytetowy proces zarygluje (ang. lock) zasób i zostanie wywłasz-
czony przez proces o wyższym priorytecie.
Kiedy drugi proces bą dzie próbował uzyskać dostą p do zasobu, zostanie zablokowany.
Jeśli w tym momencie pojawi sią trzeci proces, o średnim priorytecie, wywłaszczy proces
niskopriorytetowy i bą dzie sią wykonywać kosztem procesu o najwyższym priorytecie.
Ponieważ zadanie o średnim priorytecie wykonuje sią , gdy istnieje zadanie o wyższym
priorytecie, de facto priorytety zadań są odwrócone (ang. priority inversion).
Rozdział 2. f& RTLinux 25
Dla uniknią cia takiego niekorzystnego zjawiska w literaturze [4, 22] poświą conej tej
tematyce zostało zaproponowanych kilka modeli dostą pu do zasobów dzielonych. Dla
pokazania istoty problemu rozważmy dwa z nich, przy założeniu, że dla procesów (zadań)
i zasobów prawdziwe są nastą pujące stwierdzenia:
do procesów przypisane są statyczne priorytety,
zasoby są dostą pne w sposób wzajemnie wykluczający sią ,
używany jest scheduler planujący zadania na podstawie ich priorytetu
(gdzie procesor dostaje gotowe zadanie o najwyższym priorytecie),
zasoby, do których proces ma dostą p, są znane z góry, przed uruchomieniem
procesu.
Najprostszą techniką dostą pu do danych dzielonych wydaje sią być protokół bazujący na
dziedziczeniu priorytetów (ang. priority-inheritance protocol), w którym proces uży-
wający zasobu potrzebnego procesowi o wysokim priorytecie dziedziczy jego priorytet
dopóki, dopóty nie przestanie korzystać z zasobu bą dącego przedmiotem sporu. Po zwol-
nieniu zasobu jego priorytet uzyskuje pierwotną wartość, zatem możliwość wywłaszczenia
procesu niskopriorytetowego w jego sekcji krytycznej przez proces o średnim priorytecie
zostaje wyeliminowana. Niestety, takie rozwiązanie niesie ze sobą poważne zagrożenia.
Jeśli w rozważanym poprzednio przykładzie proces, który odziedziczył wysoki priorytet
w sposób zagnieżdżony, zażąda dostą pu do drugiego zasobu aktualnie używanego przez
zablokowany proces o wysokim priorytecie, nastąpi zakleszczenie (ang. impas).
Ponieważ dziedziczenie priorytetów nie eliminuje niedopuszczalnego w systemach czasu
rzeczywistego zakleszczenia procesów, twórcy systemu RTLinux nie stosują tego pro-
tokołu w obiektach synchronizacji, służących do ochrony zasobów dzielonych. Z całkiem
bogatej rodziny protokołów dostą pu, bazujących na stałym priorytecie, RTLinux im-
plementuje protokół CSP (ang. Ceiling Semaphore Protocol). Działanie protokołu
opiera sią na poją ciu pułapu priorytetu, przypisanego do zasobu. Pułap zasobu ma wartość
równą najwyższemu priorytetowi spośród procesów, które mogą go zająć. Idea dzia-
łania protokołu CSP polega na ustawianiu priorytetu procesu, który posiadł zasób, na
wartość pułapu tego zasobu. Proces działa z priorytetem równym pułapowi zasobu aż do
jego zwolnienia.
Przykład 2.3. Działanie protokołu CSP
Rozważmy dla przykładu procesy p1, p2 i p3 o relacji priorytetów p1>p2>p3, które
próbują uzyskać wyłączny dostą p do zasobu R, jak na rysunku 2.2.
Rysunek 2.2.
Działanie protokołu
Ceiling Semaphore
Protocol [22]
26 RTLinux system czasu rzeczywistego
Rysunek 2.2 prezentuje nastą pującą sekwencją zdarzeń, przy założeniu, że pułap zasobu R
jest równy 1:
t = 0: pojawia sią p3 i wykonuje sią ;
t = 1: p3 żąda i zajmuje zasób R, p3 dziedziczy pułap priorytetu równy 1;
t = 2: pojawia sią p2, lecz p3 wykonuje sią dalej, jako proces o wyższym priorytecie;
t = 3: pojawia sią p1, lecz dalej wykonuje sią p3, ponieważ p1 nie ma wyższego
priorytetu;
t = 4: p3 kończy sekcją krytyczną zwalnia R i wraca do poprzedniego priorytetu;
t = 5: wykonuje sią p1;
t = 6: p1 alokuje R ;
t = 7: p1 kończy sekcją krytyczną, wykonuje sią i kończy;
t = 8: wykonuje sią p2;
t = 9: p2 zajmuje R;
t =10: p2 kończy sekcją krytyczną, wykonuje sią i kończy;
t =11: p3 wykonuje sią i kończy.
Protokół CSP posiada kilka zalet:
Po pierwsze, protokół zabezpiecza przed wystąpieniem zakleszczenia.
Po drugie, unika czą stego przełączania kontekstu w porównaniu z innymi
protokołami ze swojej klasy.
Trzecią zaletą jest zredukowana złożoność w trakcie wykonywania, protokół jest
przejrzysty i przewidywalny.
Wadą, jakiej można sią dopatrzyć, jest zwią kszony czas odpowiedzi, można to zauważyć
w przykładzie 2.3. Jeśli proces p3 zajmie zasób R, jego priorytet zostanie podwyższony
do pułapu R, w tym wypadku do 1. Wykonywanie procesu p2 zostanie zablokowane, nawet
jeśli nie bą dzie oczekiwał na zwolnienie zasobu.
Obecnie RTLinux dostarcza podstawowych mechanizmów synchronizacji i wzajemnego
wykluczania w postaci semaforów i muteksów zgodnych z POSIX. Oprócz podstawowych
operacji ryglowania (ang. lock) i zwalniania zasobu (ang. unlock) za pomocą semaforów
możliwe jest również ryglowanie warunkowe. W takim wypadku przy wykonywaniu ope-
racji czekaj na semaforze podawany jest limit czasu, przez jaki zadanie może czekać
na podniesienie semafora. Muteksy (ang. mutex mutual exclusion) mogą opcjonalnie
zostać wyposażone w atrybuty pozwalające na realizacją omawianego protokołu CSP
przy dostą pie do zasobów. Możliwość korzystania z tego protokołu jest ustalana przy kon-
figuracji i instalacji RTLinuksa.
Wyszukiwarka
Podobne podstrony:
Systemy czasu rzeczywistegotomasz szmuc programowanie systemow czasu rzeczywistego wykladSystemy czasu rzeczywistegosystemy rozproszone i czasu rzeczywistegoEarthdawn System Czasu WolnegoKARTOS 8–bitowe jądro czasu rzeczywistego, część 2MikroTik jako monitor ruchu czasu rzeczywistegoKARTOS 8–bitowe jądro czasu rzeczywistego, część 3KARTOS 8–bitowe jądro czasu rzeczywistego, część 3DS1307ZN zegar czasu rzeczywistego do zegarka do autaKARTOS 8–bitowe jądro czasu rzeczywistego, część 4systemy czasu pracySystem czasu pracy kierowcyVista Pomiar czasu ładowania systemuwięcej podobnych podstron