Які причини того, що стек Java / Linux не може бути "реальним часом"?

Я часто чув, як розробники згадують, що Java не може " робити в реальному часі ", тобто додаток Java, що працює на Linux, не може відповідати вимогам детермінованої системи реального часу, наприклад, що працює на RIOT-OS тощо.

Я намагаюся зрозуміти, чому . Мій SWAG каже мені, що це, мабуть, багато в чому пов’язано з збирачем сміття Java, який може працювати в будь-який час і повністю призупиняти систему. І хоча там є так звані "паузальні ГК", я не обов'язково вірю їх рекламі, а також не маю 80 000 доларів за JVM-екземпляр, щоб розщедритися на проект хобі!

Я також читав цю статтю про запуск безпілотного програмного забезпечення в Linux . У цій статті автор описує сценарій, коли Linux ледь не спричинив, що його дрон врізався в його автомобіль:

Я навчився важкого уроку після того, як вирішив зробити цикл керування низьким рівнем (PID) на Pi - намагаючись бути розумним, я вирішив поставити запис журналу в середину циклу для налагодження - четвірка спочатку пролетіла добре, але потім Linux вирішив щоб зайняти 2 секунди, щоб написати один запис в журнал, і квадроцикл майже врізався в мій автомобіль!

Тепер, хоча цей автор написав своє програмне забезпечення для безпілотника на C ++, я б міг уявити, що додаток Java, що працює під управлінням Linux, може дуже спіткати таку ж долю.

За даними Вікіпедії:

Кажуть, що система є в реальному часі, якщо повна правильність операції залежить не тільки від її логічної правильності, але і від часу, в якому вона виконується.

Тому для мене це означає "у вас немає реального часу, якщо повна коректність вимагає логічної коректності та своєчасності ".

Давайте зробимо вигляд, що я написав програму Java, що вона є надзвичайно ефективною, і що я "стиснув лимон" так би мовити, і це не могло розумно написати (на Java), щоб бути швидшим.

Загалом, моє запитання таке: я шукаю когось, який би мені пояснив усі / більшість причин того, чому програма Java, що працює під управлінням Linux, не буде «додатком у реальному часі». Що означає, що всі категорії речей на стеку Java / Linux не дозволяють йому бути "своєчасним", а отже, бути " абсолютно правильним "? Як уже згадувалося, схоже, що зчитування журналу GC та Linux може призупинити виконання, але я впевнений, що поза цим додатком Java є ще багато речей, які можуть спричинити погані терміни / продуктивність та призвести до жорстких обмежень щодо терміну. Хто вони?

Програмне забезпечення в режимі реального часу відбувається не тоді, коли це відбувається якнайшвидше, але коли гарантується, що процес завершиться протягом певного визначеного проміжку часу. У м'якій системі реального часу добре, але не зовсім необхідно, щоб це було гарантовано. Наприклад, в грі обчислення, необхідні для кадру, повинні завершитися протягом періоду кадру, інакше частота кадрів знизиться. Це погіршує якість ігрового процесу, але не робить його неправильним. Наприклад, Minecraft приємний, навіть якщо гра час від часу заїкається.

У жорсткій системі реального часу таких свобод у нас немає. Програмне забезпечення управління польотом повинне реагувати протягом певного терміну, інакше транспортний засіб може врізатися. А обладнання, ОС та програмне забезпечення повинні працювати разом, щоб підтримувати реальний час.

Наприклад, в ОС є планувальник, який визначає, який саме потік запускається. Для програми в режимі реального часу планувальник повинен гарантувати досить великі, досить часті проміжки часу. Будь-який інший процес, який хоче виконати в такому слоті, повинен бути перерваний на користь процесу в режимі реального часу. Для цього потрібен планувальник із чіткою підтримкою в режимі реального часу.

Також програма для користувальницького простору здійснюватиме системні виклики в ядро. У ОС в реальному часі вони теж повинні бути в режимі реального часу. Наприклад, запис у ручку файлу повинен бути гарантовано зайняти не більше x одиниць часу, що вирішить проблему журналу. Це впливає на те, як можна реалізувати такий системний виклик, наприклад, як можуть використовуватися буфери. Це також означає, що виклик повинен бути відмовним, якщо він не може завершитися протягом необхідного часу, і що програма простору користувача повинна бути готова вирішувати ці випадки. У випадку з Java, JVM та стандартна бібліотека також схожі на ядро ​​і потребують явної підтримки в реальному часі.

Що стосується реального часу, ваш стиль програмування зміниться. Якщо у вас немає нескінченного часу, вам доведеться обмежитися невеликими проблемами. Усі ваші петлі повинні бути обмежені деякою константою. Вся пам'ять може бути розподілена статично, оскільки у вас є верхня межа розміру. Необмежена рекурсія заборонена. Це суперечить безлічі кращих практик, але вони не застосовуються до систем реального часу. Наприклад система реєстрації може використовувати статично виділений буфер дзвінка для зберігання повідомлень журналу, коли вони записуються. Як тільки початок буде досягнуто, старі журнали будуть відкинуті, або ця умова може бути помилкою.

З Вікіпедії :

Ключовою характеристикою RTOS є рівень його узгодженості щодо часу, необхідного для прийняття та виконання завдання програми; мінливість - тремтіння.

Важливим є те, що тремтіння визначається кількісно, ​​щоб система розглядалася в режимі реального часу . У статті йдеться про те, що якщо тремтіння зазвичай обмежене, система працює в режимі реального часу . Якщо тремтіння завжди обмежене, система є жорсткою в режимі реального часу .

Якщо версії Java та Linux, які ви використовуєте, не оцінюються кількісно з точки зору тремтіння, вони не в режимі реального часу. Збір сміття та написання журналів - це, безумовно, джерело тремтіння, але навіть автономна обробка (наприклад) мережевих пакетів підраховується, якщо це впроваджує тремтіння у ваші процеси.

Для початку сам ванільний Linux не може реально працювати. Ось чому був розроблений RTLinux .

Скажімо, ви запускаєте кілька Java-процесів на RTLinux, вони все одно вважатимуться в реальному часі, оскільки всі ці процеси заплановані ядром, тобто якщо один процес запізнюється, інші процеси все ще можуть мати свій фрагмент часу процесора, гарантовано.

Тепер, якщо в Java-процесах запущені зелені нитки , то виконання цих потоків більше не буде в реальному часі, оскільки JVM не здійснює планування в реальному часі.