Jakie są powody, dla których stos Java / Linux nie jest „w czasie rzeczywistym”?

Często słyszałem, jak programiści wspominali, że Java nie może „ robić w czasie rzeczywistym ”, co oznacza, że ​​aplikacja Java działająca w systemie Linux nie może spełniać wymagań deterministycznego systemu czasu rzeczywistego, takiego jak coś działającego w systemie RIOT-OS itp.

Próbuję zrozumieć, dlaczego . Mój SWAG powiedział mi, że jest to prawdopodobnie w dużej mierze spowodowane Javy Garbage Collector, który może działać w dowolnym momencie i całkowicie wstrzymywać system. I chociaż istnieją tak zwane „bez przerwy GC”, niekoniecznie wierzę w ich reklamy, a także nie mam instancji o wartości 80 000 USD na JVM, którą można by przeznaczyć na projekt hobby!

Czytałem również ten artykuł na temat uruchamiania oprogramowania dronów w systemie Linux . W tym artykule autor opisuje scenariusz, w którym Linux prawie spowodował awarię jego drona w samochodzie:

Nauczyłem się trudnej lekcji po wybraniu wykonania pętli sterowania niskim poziomem (PID) na Pi - starając się być sprytny postanowiłem umieścić zapis dziennika w środku pętli w celu debugowania - quad początkowo leciał dobrze, ale potem Linux zdecydował 2 sekundy na napisanie jednego wpisu do dziennika, a quad prawie rozbił się w moim samochodzie!

Teraz, chociaż autor napisał swoje oprogramowanie dronów w C ++, wyobrażam sobie, że aplikacja Java działająca w systemie Linux mogłaby równie dobrze spotkać ten sam los.

Według Wikipedii:

Mówi się, że system działa w czasie rzeczywistym, jeśli całkowita poprawność operacji zależy nie tylko od jej logicznej poprawności, ale także od czasu jej wykonania.

Dla mnie oznacza to zatem: „ Nie masz czasu rzeczywistego, jeśli całkowita poprawność wymaga logicznej poprawności i aktualności ”.

Udawajmy, że napisałem aplikację Java, aby była super wydajna, i że „ścisnęłam cytrynę”, że tak powiem, i nie można było rozsądnie napisać (w Javie), żeby była szybsza.

Podsumowując, moje pytanie brzmi: szukam kogoś, kto wyjaśni mi wszystkie / większość powodów, dla których aplikacja Java działająca pod Linuksem nie byłaby „aplikacją czasu rzeczywistego”. To znaczy, jakie są wszystkie kategorie rzeczy na stosie Java / Linux, które uniemożliwiają mu „bycie na czas”, a zatem „ całkowitą poprawność ”? Jak wspomniano, wygląda na to, że płukanie dzienników GC i Linux może wstrzymać wykonanie, ale jestem pewien, że poza samą aplikacją Java jest więcej rzeczy, które mogłyby spowodować złe wyczucie czasu / wydajność i spowodować, że będzie ona musiała sprostać ograniczonym terminom. Czym oni są?

Oprogramowanie działa w czasie rzeczywistym nie wtedy, gdy jest tak szybkie, jak to możliwe, ale gdy gwarantuje się, że proces zakończy się w określonym przedziale czasowym. W miękkim systemie czasu rzeczywistego jest to gwarantowane, ale nie absolutnie konieczne. Np. W grze obliczenia konieczne do wykonania klatki powinny zakończyć się w okresie klatki, w przeciwnym razie liczba klatek spadnie. To obniża jakość rozgrywki, ale nie czyni jej niepoprawną. Na przykład Minecraft jest przyjemny, chociaż gra czasami się zacina.

W trudnym systemie czasu rzeczywistego nie mamy takich swobód. Oprogramowanie do sterowania lotem musi zareagować w określonym terminie, w przeciwnym razie pojazd może ulec awarii. Sprzęt, system operacyjny i oprogramowanie muszą ze sobą współpracować, aby obsługiwać w czasie rzeczywistym.

Na przykład system operacyjny ma harmonogram, który decyduje o tym, który wątek ma zostać uruchomiony. W przypadku programu działającego w czasie rzeczywistym program planujący musi zagwarantować wystarczająco duże, wystarczająco częste przedziały czasowe. Każdy inny proces, który chce zostać wykonany w takim gnieździe, musi zostać przerwany na korzyść procesu w czasie rzeczywistym. Wymaga to harmonogramu z wyraźnym wsparciem w czasie rzeczywistym.

Ponadto program przestrzeni użytkownika wykona wywołania systemowe w jądrze. W systemie operacyjnym czasu rzeczywistego również one muszą być w czasie rzeczywistym. Np. Zapisywanie do uchwytu pliku musiałoby gwarantować, że nie zajmie więcej niż x jednostek czasu, co rozwiązałoby problem z logowaniem. Wpływa to na sposób realizacji takiego wywołania systemowego, np. Na sposób wykorzystania buforów. Oznacza to również, że wywołanie musi zakończyć się niepowodzeniem, jeśli nie może zostać zakończone w wymaganym czasie, oraz że program przestrzeni użytkownika musi być przygotowany do obsługi tych przypadków. W przypadku Javy JVM i biblioteka standardowa są również podobne do jądra i wymagałyby wyraźnego wsparcia w czasie rzeczywistym.

Wszystko, co dzieje się w czasie rzeczywistym, zmieni Twój styl programowania. Jeśli nie masz nieskończonego czasu, musisz ograniczyć się do drobnych problemów. Wszystkie twoje pętle muszą być ograniczone jakąś stałą. Całą pamięć można przydzielić statycznie, ponieważ masz górną granicę rozmiaru. Nieograniczona rekurencja jest zabroniona. Jest to sprzeczne z wieloma najlepszymi praktykami, ale nie dotyczą one systemów działających w czasie rzeczywistym. Na przykład system rejestrowania może użyć statycznie przydzielonego bufora pierścieniowego do przechowywania komunikatów dziennika podczas ich zapisywania. Po osiągnięciu początku stare dzienniki zostaną odrzucone, w przeciwnym razie może to być błąd.

Z wikipedii :

Kluczową cechą RTOS jest poziom jego spójności pod względem czasu potrzebnego do zaakceptowania i wykonania zadania aplikacji; zmienność jest niestabilna.

Ważną rzeczą jest to, że drgania są kwantyfikowane, aby system mógł być uważany za rzeczywisty . Artykuł dalej mówi, że jeśli jitter jest zwykle ograniczony, system działa w czasie rzeczywistym miękko . Jeśli fluktuacja jest zawsze ograniczona, system jest trudny w czasie rzeczywistym .

O ile wersje Java i Linux, których używasz, nie są skwantyfikowane, nie są one wyświetlane w czasie rzeczywistym. Wyrzucanie elementów bezużytecznych i zapisywanie dzienników są z pewnością źródłem fluktuacji, ale nawet autonomiczne przetwarzanie (np.) Pakietów sieciowych ma znaczenie, jeśli wprowadza fluktuacje do twoich procesów.

Na początek sam waniliowy Linux nie może działać w czasie rzeczywistym. Właśnie dlatego opracowano RTLinux .

Załóżmy, że uruchamiasz kilka procesów Java w RTLinux, nadal będą one uważane za działające w czasie rzeczywistym, ponieważ wszystkie te procesy są planowane przez jądro, tj. Jeśli jeden proces się spóźni, inne procesy mogą mieć zagwarantowany wycinek czasu procesora.

Teraz, jeśli procesy Java wykonują Zielone wątki , wówczas wykonanie tych wątków nie będzie już wykonywane w czasie rzeczywistym, ponieważ JVM nie wykonuje planowania w czasie rzeczywistym.