Mariusz Rudnicki PROGRAMOWANIE SYSTEMÓW CZASU RZECZYWISTEGO CZ.2

Transkrypt

1 Mariusz Rudnicki PROGRAMOWANIE SYSTEMÓW CZASU RZECZYWISTEGO CZ.2

2 Architektura - Procesy Proces program załadowany do pamięci; identyfikowany przez id procesu, zwykle nazywany jako pid; wspólne zasoby procesu: pamięć, włączając kod i dane, otwarte pliki, identyfikatory : id użytkownika, id grupy, timery. Zasoby należące do jednego procesu są chronione przed innymi procesami. 2/37

3 Architektura - Wątki Wątek wątek jest pojedynczym strumieniem wykonania; wątek posiada pewne atrybuty: priorytet, algorytm kolejkowania, zestaw rejestrów, maska CPU dla SMP, maska sygnałów, i inne. 3/37

4 Architektura - Procesy i Wątki Wątki są uruchamiane wewnątrz procesów: proces musi posiadać przynajmniej jeden wątek; wątki w procesie współdzielą wszystkie zasoby procesu. 4/37

5 Architektura - Procesy i Wątki Procesy i wątki: procesy są komponentami składowymi systemu, które: widoczne dla każdego innego procesu; mogą komunikować się z każdym procesem, wątki są szczegółową implementacją danego procesu: ukrytą w jego wnętrzu. 5/37

6 Architektura Jądro Funkcje jądra: są spoiwem łączącym cały system; programy mają do czynienia z jądrem za pomocą specjalnych procedur bibliotecznych, nazywanych wywołaniami jądra ang. kernel calls, które wykonują kod umieszczony w jądrze; większość podsystemów, włączając aplikacje użytkownika, komunikują się nawzajem używając mechanizmu przekazywania wiadomości, dostarczanego przez jądro za pomocą wywołań jądra. 6/37

7 Architektura Jądro Jądro jest rdzeniem systemu: Wywołania jądra: często będziemy korzystać z wywołań jądra, np. w trakcie komunikacji IPC lub podczas obsługi przerwań, timerów, wątków itp.; to znaczy, że będzie wykonywany kod w jądrze podczas wywołania. Co się wydarzy jeżeli wystąpi krytyczne zdarzenie w trakcie wykonywania kernell calls? 7/37

8 Jądro Wywłaszczanie Wywołania jądra są wywłaszczające: 8/37

9 Jądro Wywłaszczanie Operacje jądra: 9/37

10 Jądro Wywłaszczanie Jakie są zalety i wady wywłaszczania? Więcej ustępstw: korzyści: zmniejszone opóźnienie; szybsza odpowiedź na nowe zdarzenia; krótsze opóźnienie przerwania, koszty: wydajność wymaga więcej czasu by wznowić przerwane wywołanie jądra; zabiera więcej czasu i zasobów na zachowanie aktualnego stanu i wznowienie wywłaszczonego procesu przekazywania wiadomości. 10/37

11 Jądro Usługi 11/37

12 Jądro IPC Formy IPC Inter-Process Communication dostarczane przez jądro: Komunikaty - wymiana informacji między procesami. Pulsy - dostarczenie zawiadomienia do procesu. Sygnały - przerwanie procesu i wykonanie innej części kodu lub zakończenie. 12/37

13 Jądro IPC Komunikaty QNX Neutrino : 13/37

14 Jądro IPC Pulsy QNX Neutrino używane do powiadamiania o zdarzeniu: coś się zdarzyło. 14/37

15 Jądro IPC Sygnały zgodne ze specyfikacją POSIX używane np. do przerwania procesu. 15/37

16 Jądro Wątki Funkcje związane z wątkami obsługa wątków zgodna ze standardem POSIX: dynamiczne tworzenie / usuwanie wątków; oczekiwanie na zakończenie wątku; zmiana atrybutów wątku. 16/37

17 Jądro synchronizacja wątków Mutex wzajemne wykluczenie wątków Condvar oczekiwanie na zmienną Semaphore oczekiwanie na licznik RWlock synchronizacja wątków piszących i czytających Join synchronizacja do zakończenia wątku Spinlock oczekiwanie na alokację pamięci Sleepon podobnie do condvars, z dynamiczną alokacją Barrier oczekiwanie na określoną liczbę wątków 17/37

18 Jądro czas Koncepcja czasu w QNX Neutrino : 18/37

19 Jądro Przerwania Koncepcja przerwań w QNX Neutrino : Obsługa przerwań: Wszystkie przerwania sprzętowe są przekazywane do jądra. Proces: może zarejestrować funkcję, która będzie wywołana przez jądro po wystąpieniu przerwania; żądać powiadomienia o wystąpieniu zdarzenia. 19/37

20 QNX Neutrino Przerwania Wywołania dla przerwań: id = InterruptAttach (int intr, struct sigevent *(*handler)(void *, int), void *area, int size, unsigned flags); id = InterruptAttachEvent (int intr, struct sigevent *event, unsigned flags); InterruptDetach (int id); InterruptWait (int flags, uint64_t *reserved); InterruptMask (int intr, int id); InterruptUnmask (int intr, int id); InterruptLock (struct intrspin *spinlock); InterruptUnlock (struct intrspin *spinlock); Musimy uzyskać uprawnienia I/O dla tych funkcji. W tym celu wywołujemy ThreadCtl(_NTO_TCTL_IO, 0), poza tym wymagane są uprawnienia root (userid 0). 20/37

21 QNX Neutrino Przerwania Obsługa przerwań: Przykład sterownika A: z wykorzystaniem funkcji obsługi przerwania ISR. struct sigevent event; const struct sigevent *handler (void *not_used, int id){ } if (check_status_register()) else return (&event); return (NULL); main (){ ThreadCtl (_NTO_TCTL_IO, 0); SIGEV_INTR_INIT (&event); id = InterruptAttach (intnum, handler, NULL, 0,...); while(1){ InterruptWait (0, NULL); // do some or all of the work here } } 21/37

22 QNX Neutrino Przerwania Obsługa przerwań: Przykład sterownika B: z wykorzystaniem zdarzenia powiązanego z przerwaniem tzw. obsługa w wątku. struct sigevent event; main(){ } ThreadCtl (_NTO_TCTL_IO, 0); SIGEV_INTR_INIT (&event); id = InterruptAttachEvent (intnum, &event,...); for (;;) { } InterruptWait (0, NULL); // do the interrupt work here, at thread priority InterruptUnmask (intnum, id); 22/37

23 QNX Neutrino Przerwania Do zadań poniższych funkcji należy poinformowanie jądra, która część kodu programu musi być wykonana po wystąpieniu przerwania: 23/37

24 QNX Neutrino Przerwania Parametr flagi: _NTO_INTR_FLAGS_END Dotyczy kolejności wykonywania procedur obsługi przerwań przypisanych do jednego przerwania. SO QNX6 pozwala na dzielenie przerwań. Oznacza to, że do jednego przerwania przypisanych może być wiele handlerów tworzących łańcuch. Domyślnie nowy handler umieszczany jest na początku łańcuch, co znaczy, że po przyjściu przerwania wykona się jako pierwszy. Kolejność tę można zmienić ustawiając flagę _NTO_INTR_FLAGS_END. Nowy handler dopisany będzie na końcu łańcucha i wykona się jako ostatni. 24/37

25 QNX Neutrino Przerwania Parametr flagi: _NTO_INTR_FLAGS_PROCESS Gdy flaga ta jest ustawiona, to system kojarzy handler z procesem, a nie z wątkiem. Oznacza to, że handler będzie deinstalowany, gdy kończy się proces, a nie wątek, który zarejestrował ISR. 25/37

26 QNX Neutrino Przerwania Parametr flagi: _NTO_INTR_FLAGS_TRK_MSK Ma znaczenie, gdy do jednego przerwania dołączonych jest wiele handlerów. Na przykład, gdy zainstalowane są dwa handlery i jeden z nich maskuje przerwanie, to ma ono pozostać zamaskowane tylko dla tego handlera. ZAWSZE musi być ustawiona. 26/37

27 QNX Neutrino Przerwania Właściwości funkcji obsługi przerwania: Rozmiar stosu, którym dysponuje procedura obsługi przerwania, jest ograniczony. Stąd nie powinna ona zawierać dużych tablic czy innych struktur danych. Bezpiecznie jest przyjąć, że dostępny rozmiar stosu wynosi około 200 bajtów. Procedura obsługi przerwań jest wykonywana asynchronicznie z wątkami należącymi do pewnego procesu i używa wspólnych z nimi danych. Wszystkie zmienne modyfikowane przez handler powinny być poprzedzone słowem kluczowym volatile a ich modyfikacja wewnątrz wątków zabezpieczona przez zablokowanie przerwań. Innym rozwiązaniem jest zastosowanie funkcji realizujących elementarne operacje arytmetyczne i bitowe w niepodzielny sposób. Nazwy tych funkcji zaczynają się od atomic_*. 27/37

28 QNX Neutrino Przerwania Właściwości funkcji obsługi przerwania: Procedura obsługi przerwania jest wykonywana poza normalnym szeregowaniem, więc powinna być krótka, jak to tylko możliwe. Jeżeli wymagane jest wykonanie czasochłonnych czynności, to powinny być one wykonane w wątku, który zostanie odblokowany przez handlera. Procedura obsługi przerwania nie może wywoływać żadnych funkcji systemowych poza sporadycznymi wyjątkami. 28/37

29 QNX Neutrino Przerwania Handler vs. event Rozmiar stosu, którym dysponuje procedura obsługi przerwania, jest ograniczony. Stąd nie powinna ona zawierać dużych tablic czy innych struktur danych. Procedura obsługi przerwań jest wykonywana poza normalnym szeregowaniem, więc powinna być tak krótka, jak to tylko możliwe. Jeżeli wymagane jest wykonanie czasochłonnych czynności, to powinny być one wykonane w wątku, który zostanie przez handler odblokowany. 29/37

30 QNX Neutrino Przerwania Handler vs. event Odblokowany przez zdarzenie wątek ma priorytet i podlega zwykłemu szeregowaniu. Uruchamianie wątków jest łatwiejsze niż handlerów. Większa zwłoka pomiędzy przerwaniem a odblokowaniem wątku. W kodzie procedury obsługi przerwania należy wykonać tylko niezbędne czynności, a następnie powiadomić pewien wątek o wystąpieniu przerwania. Wątek ten wykona resztę pracy. 30/37

31 RT Linux Przerwania Wirtualny mechanizm przerwań jest kluczowym elementem architektury RT Linuxa. Wszystkie przerwania sprzętowe przechwytywane są przez RT Core. RT Core jednocześnie emuluje kontrolera przerwań na potrzeby zwykłego Linuxa, który pracuje tak jakby odbierał przerwania sprzętowe. 31/37

32 RT Linux Przerwania Jeżeli w systemie istnieje RT ISR to jest ona uruchamiana. W przeciwnej sytuacji, gdy przerwanie nie jest skojarzone z zadaniem krytycznych to przerwanie takie jest przekazywane do zwykłego Linuxa, pod warunkiem, że żadne zadanie krytyczne nie jest w danej chwili wykonywane. 32/37

33 RT Linux Przerwania Linux blokuje w niektórych sytuacjach przerwania (np. podczas synchronizacji). RT Linux zapamiętuje taką sytuację. Przychodzące przerwanie oznaczone jest jako oczekujące. Jego zgłoszenie nastąpi natychmiast po odblokowaniu przerwań w Linuxie. Dzieje się tak dzięki zamianie w kodzie jądra Linuxa instrukcji cli, sti i iret odpowiednio na makra S_CLI, S_STI, S_IRET. 33/37

34 Windows CE Przerwania Wzajemne powiązania pomiędzy komponentami kernel mode interrupt i wbudowanymi sterownikami urządzeń oraz sprzętem. OAL - OEM Adaptation Layer 34/37

35 Windows CE Przerwania Przykładowa sekwencja obsługi przerwania: jeżeli moduł Exception handler odbierze przerwanie sprzętowe i jądro wykryje wyjątek wówczas jądro obsłuży przerwanie. W przeciwnym wypadku; moduł jądra wspierający obsługę przerwań powiadamia ISR, aby zablokowała właściwe przerwanie do momentu zakończenia jego obsługi (pozostałe przerwania są odblokowane); moduł obsługi wyjątków wywołuje ISR aby określić sposób obsługi przerwania; 35/37

36 Windows CE Przerwania Moduł ISH odbiera wartość zwracaną z ISR, która określa co należy zrobić z przerwaniem: SYSINTR_NOP do nothing; SYSINTR_RESCHED jądro przeszeregowuje IST; SYSINTR_XXX, logical interrupt value jądro pobudzone przez ISR budzi wątek IST, który wykonuje swoją pracę. IST tworzy zdarzenie i oczekuje na nie; obudzony IST wykonuje całą pracę wymaganą do obsługi przerwania; jeśli zachodzi taka konieczność IST wywołuje różnego rodzaju funkcje I/O za pomocą, których uzyskuje dostęp do sprzętu w celu wykonania swojej pracy; IST kończy swoją pracę powiadamiając jądro poprzez wywołanie InterruptDone. jądro wywołuje funkcję OAL OEMInterruptDone w celu zakończenia obsługi przerwania. OAL powiadamia sprzęt w celu odblokowania przerwania. 36/37

37 Windows CE Przerwania Obsługa przerwań podzielona jest na dwie części: Kernel mode interrupt service routine ISR, User mode interrupt service thread IST; Funkcja ISR powinna wykonać minimum pracy niezbędnej do obsługi przerwania: ISR może odczytać dane z urządzenia do bufora w przypadku gdy istnieje ryzyko utraty danych lub nadpisania danych przez kolejne przerwanie; ISR czyści flagi przerwania w urządzeniu; ISR zwraca SYSINTR do jądra systemu; Jądro uruchamia zdarzenie powiązane z przerwaniem, które odblokowuje IST, który odpowiada ISR; Planista szereguje IST. IST kończy obsługę przerwania. 37/37