Systemy czasu rzeczywistego i opóźnienia

System czasu rzeczywistego musi odpowiedzieć w określonym terminie. Przekroczenie terminu powoduje awarię:

• Twardy czas rzeczywisty — przekroczenie terminu oznacza awarię systemu (systemy medyczne, awionika)
• Miękki czas rzeczywisty — przekroczenie terminów pogarsza jakość, ale jest akceptowalne (audio, wideo)

Kod czasu rzeczywistego wymaga przewidywalnego czasu wykonania, a nie maksymalnej wydajności. Funkcja, która zawsze wykonuje się przez 10 µs, jest preferowana względem funkcji wykonującej się przez 1–20 µs.

Operacje na stercie są nieprzewidywalne — wpływają na nie fragmentacja i decyzje alokatora. Pamięć należy alokować podczas uruchamiania i ponownie wykorzystywać. Standardy programowania systemów wbudowanych często zabraniają używania new poza kodem inicjalizacyjnym.

Rzucanie wyjątków ma nieprzewidywalny koszt. Większość kodu C++ czasu rzeczywistego kompiluje się z opcją -fno-exceptions.

Funkcje wirtualne dodają dodatkowy poziom pośredni i mogą pogarszać predykcję rozgałęzień. Do polimorfizmu statycznego używaj szablonów lub CRTP.

Blokady mogą powodować inwersję priorytetów — wątek o niskim priorytecie, który posiada blokadę, blokuje wątek o wysokim priorytecie. Struktury danych bez blokad pozwalają uniknąć tego problemu.

Jeśli blokady są konieczne, należy preferować te obsługujące dziedziczenie priorytetów — system operacyjny tymczasowo podnosi priorytet wątku posiadającego blokadę.

Przeanalizuj najgorszą ścieżkę wykonania kodu. Narzędzia i analiza manualna pozwalają oszacować maksymalną liczbę cykli, jaką może zająć funkcja. WCET wpływa na decyzje dotyczące harmonogramowania.

W systemach twardego czasu rzeczywistego używaj systemu RTOS (FreeRTOS, Zephyr, VxWorks) albo programuj bezpośrednio na sprzęcie. Systemy ogólnego przeznaczenia mogą bezterminowo opóźnić wykonanie zadania.

Braki w pamięci podręcznej i TLB powodują nieprzewidywalne przestoje. Najbardziej krytyczne dane można zablokować w pamięci podręcznej albo umieścić w pamięci RAM typu scratchpad.

Pamięć należy alokować z wcześniej przygotowanych pul zamiast ze zwykłej sterty. Alokacja i zwalnianie mają stały czas wykonania. Wiele projektów wbudowanych w C++ korzysta wyłącznie z takich pul.

Wydajność na komputerze roboczym ma niewiele wspólnego z wydajnością na MCU. Zawsze mierz wydajność na docelowym sprzęcie przy realistycznym obciążeniu.

Dlaczego alokacje na stercie są problematyczne w kodzie C++ czasu rzeczywistego?

W kodzie C++ czasu rzeczywistego przewidywalność jest ważniejsza niż maksymalna wydajność. Należy unikać sterty, wyjątków, wywołań wirtualnych i blokad zarządzanych przez system operacyjny. Należy używać pamięci statycznej, pul pamięci i struktur bez blokad, a także analizować czas wykonania w najgorszym przypadku. Wydajność należy mierzyć na rzeczywistym urządzeniu docelowym.