Які гарантії насправді надають “м'які” операційні системи в режимі реального часу


17

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

Усі визначення, які я знаходжу для "м'яких" систем у реальному часі, здаються мені вакуумними. У Вікіпедії йдеться

корисність результату погіршується після його строку, тим самим погіршуючи якість обслуговування системи.

Уххх. Добре. За цими критеріями Windows 95 була м'якою системою реального часу, як і 3BSD, а також Linux. Вікіпедія не є чудовим джерелом, але наступна пара хітів Google не набагато краща. Наприклад, http://users.ece.cmu.edu/~koopman/des_s99/real_time/ каже

У м'якій системі в режимі реального часу може бути допустимо погіршення роботи при рідкісному піковому навантаженні.

Це не договір, це вигадливий спосіб сказати нічого.

Які приклади реальних м'яких гарантій / реальних гарантій у реальному часі пропонують реальні операційні системи?

Я шукаю відповіді форми:

У (ім'я ОС), якщо програміст робить (що-програмісту потрібно робити), то операційна система гарантує (що-система-гарантії).

Відповіді:


22

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

Якщо ви дійсно хочете скласти слово у вигляді гарантії, це гарантія максимум зусиль, а не гарантія конкретного виконання.

Або процитувати Erlang FAQ (Erlang це мова програмування , спочатку розроблений для використання в телефонії):

Що означає м'який режим реального часу?

Циніки скажуть «в основному нічого».

(…) У багатьох телекомунікаційних системах є менш суворі вимоги [ніж у жорсткому режимі реального часу], наприклад, вони можуть вимагати статистичної гарантії відповідно до "пошуку бази даних займає менше 20 мс у 97% випадків". М’які системи в режимі реального часу, такі як Erlang, дозволяють вам зробити таку гарантію.

І це дає корисне визначення. М’який режим реального часу вказує на дизайн, який оптимізується під кожне окреме завдання, забираючи не більше певного часу , а не оптимізуючи загальний час, витрачений на виконання всіх завдань. Наприклад, м'яка система в режимі реального часу має на меті виконати 99,9% запитів за 10 мс та обробити 100 запитів в секунду, де в реальному часі може ставитись за мету обробляти 200 запитів в секунду, але дозволяти час від часу запит блокувати для 50 мс і більше. Важкий реальний час гарантував би один запит кожні 15 мс незалежно від того.

Програмне забезпечення в режимі реального часу використовується для програм, де пропущений термін означає деградацію обслуговування, але не є критичним для продуктивності. Мультимедіа та телефонія є типовими випадками використання. Кожен аудіо- чи відеокадр повинен бути відтворений часом, інакше його потрібно пропустити; але пропуск кадру - це не кінець світу. У дизайнерів Erlang були схожі цілі щодо надійності в інших питаннях: вони зауважили, що краще, щоб телефонна станція дуже періодично кидала дзвінок, але бути абсолютно впевненою, що станція в цілому продовжує працювати, чим може, ніж коли-небудь ризикує катастрофічним невдачею, намагаючись підтримувати з'єднання будь-якою ціною.

Навпаки, щось на кшталт управління двигуном вимагає, щоб програмне забезпечення ніколи не пропускало термін. Це має витрати: загальна ефективність зазвичай повільніша, і можна досягти лише відносно простого поведінки. З іншого боку спектру, додатки для стискання чисел зазвичай дбають лише про загальну продуктивність - важливо, наскільки швидко множиться матриць 1000x1000, а не як швидко обчислюється кожен стовпець.


@ E.DouglasJensen Ваше твердження - це грубе перебільшення. Ваша відповідь принципово не погоджується зі статтею Вікіпедії.
Жил "ТАК - перестань бути злим"

Так, я згоден. Мій коментар мав на меті охопити кілька сторінок Вікіпедії про реальний час, і велика частина цього вмісту в кращому випадку не розглядається.
E. Douglas Jensen

Моя найбільша скарга полягає в тому, що люди не вважають, що настільки ж жорстке програмне забезпечення в реальному часі (дотримуйтесь усіх термінів) програмне забезпечення повинно бути офіційно перевірено (скажімо) автомобільними гальмівними системами - так теж повинно бути м'яким програмне забезпечення в реальному часі (наприклад, з вірогідністю> 0,9 , принаймні 89% завдань повинні бути не більш ніж 20% термінів), обґрунтованими та офіційно підтвердженими. Усі військові бойові системи в режимі реального часу м'які. Натомість люди мають неоднозначне мислення та кажуть "Que Sera Sera".
Е. Дуглас Дженсен

"Перша революція - це коли ти передумаєш, як ти дивишся на речі і бачиш, що може бути інший спосіб поглянути на це, що тобі не показали". - Джил Скотт-Херон, "Революція не буде телевізором"
Е. Дуглас Дженсен

4

Linux з патчем -rt (в режимі реального часу) пропонує планувальник, який забезпечує цікаву гарантію, яка здається не вакуумною. (Хоча мені не ясно, як гарантію можна реально використати.)

Політика SCHED_FIFOпланування Linux-rt працює так: Користувач призначає пріоритет кожному процесу. (Номери пріоритетів для процесів "у реальному часі" становлять 0-99, а традиційні niceзначення Unix від -20 до 19 відображають на пріоритети 100-1139. (Отже, "0" - "найвищий" пріоритет, а "139" - "найнижчий" "пріоритет.)

Гарантія полягає в тому, що в будь-який час планувальник запланує заплановані завдання з Nнайвищим пріоритетом на Nпроцесорній машині. Були вжиті великі болі, щоб уникнути пріоритетних проблем з інверсією всередині ядра. Коли процес Aстане запущеним і він має більш високий пріоритет, ніж будь-який інший запущений процес B, Aбуде негайно викуплено B.

Зауважте, що строгих гарантій часу не дано. Час, витрачений фактично на виконання превенції, теоретично може бути довільним довгим. Також, мабуть, є деякі способи, за допомогою яких завдання з низьким пріоритетом можуть ініціювати купу тривалої затримки введення / виводу. Коли введення-виведення завершує обробники переривань для завдання з низьким пріоритетом, можуть перервати завдання з більш високим пріоритетом, що, мабуть, є формою інверсії пріоритету.

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

Поглиблена стаття з описом планувальника реального часу Linux - це http://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler .


1
Я думаю, що питання FAQ про RTLinux надає тут корисну характеристику (вони не використовують прикметники жорсткого або м'якого ): "Завдання з найвищим пріоритетом, яке хоче, щоб CPU завжди отримував ЦП протягом визначеного часу після того, як відбулася подія, що пробувала завдання. . ”
Жил 'SO- перестань бути злим'

4

Для визначення "м'якого режиму реального часу" найлегше порівняти його з "жорстким у режимі реального часу".

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

• якщо або в тій мірі, що це виявляється для них із затримкою (затримкою), яка може бути пов'язана з її сприйнятою валютою

• тобто у часові рамки, коли інформація або подія має для них задовільне значення.

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

Жорсткі системи в режимі реального часу роблять дуже сильні припущення, що все про додаток, систему та оточення є статичним і відомим «апріорі», наприклад, які завдання, що вони періодичні, час їх приходу, періоди, терміни, що вони виграли не матимуть конфліктів з ресурсами, і загалом еволюція системи. У системі управління польотом літака або автомобільній гальмівній системі та багатьох інших випадках ці припущення, як правило, можуть бути виконані, щоб усі строки були дотримані.

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

  • не більше 10% завдань пропускають свої терміни
  • або жодне завдання не перевищує 20%
  • або середня строковість усіх завдань не більше 15%
  • або максимальна запізнення серед усіх завдань менше 10%

Це все поширені приклади м'яких справ у реальному часі у багатьох програмах.

Розглянемо застосування одноосібного підбору дитини після школи. Це, мабуть, не має фактичного терміну, натомість є певна цінність для вас та вашої дитини залежно від того, коли відбудеться ця подія. Занадто рано витрачається на ресурси (наприклад, ваш час) і занадто пізно має певне негативне значення, оскільки ваша дитина може залишитися в спокої і, можливо, нашкодити (або принаймні незручно).

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

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

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

Основним каменем систем реального часу є "передбачуваність". Важкий випадок у реальному часі зацікавлений лише одним особливим випадком передбачуваності - тобто, щоб усі завдання відповідали своїм термінам і максимальна цінність була досягнута в рамках цієї події. Цей особливий випадок названий "детермінованим".

Існує спектр передбачуваності; Більшість систем у реальному часі (а саме м'які) мають недетерміновану передбачуваність, наприклад, часи виконання завдань, а отже, і значення, отримане в результаті цих подій. Загалом, передбачуваність, а значить, і значення, можна зробити максимально близьким до детермінованої кінцевої точки, наскільки це необхідно, але ціною, яка може бути фізично неможливою або надмірно дорогою (як у бою чи, можливо, навіть, коли вибираєте дитину зі школи).

Програмне забезпечення в режимі реального часу вимагає вибору конкретної моделі ймовірності (не загальноприйнятої частістської моделі), а отже, моделі передбачуваності для міркування про затримки подій та отримані значення.

Посилаючись на вищенаведений перелік подій, які надають прийнятне значення, тепер ми можемо додати недетерміновані випадки, такі як

  • ймовірність того, що жодне завдання не пропустить свій термін більше ніж на 5%, перевищує 0,87.

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

  • оскільки ідеальне знищення всіх ворожих ракет малоймовірне або неможливе, призначте свої оборонні ресурси, щоб збільшити ймовірність того, що якомога більшість загрозливих (наприклад, виходячи з їх цілей) ворожих ракет будуть успішно перехоплені (тісний перехоплення рахується тому, що це може рухати ворогу ракету поза ходом);

  • скаржаться, що це не проблема обчислень у режимі реального часу, оскільки вона динамічна замість статичної, а традиційні концепції та методи в реальному часі не застосовуються, тому вам не цікаво займатися науково-дослідною роботою для м'якого реального часу.

Незважаючи на різні непорозуміння щодо м'якого реального часу в обчислювальній мережі в режимі реального часу (але не в інших сферах, що не обчислюються), м'який режим реального часу є дуже загальним і потужним та, можливо, дуже складним порівняно з жорстким у реальному часі.

Щоб безпосередньо відповісти на питання ОП:

  • жорстка система в режимі реального часу може надати детерміновані гарантії - найчастіше всі завдання відповідають строкам, час переривання або системний виклик завжди буде меншим за x тощо. ЯКЩО ТА ТІЛЬКИ, якщо зроблено дуже вагомі припущення і правильно, що все, що має значення, є статичним і відомим «апріорі» (загалом, такі гарантії для жорстких систем реального часу є відкритою проблемою дослідження, за винятком досить простих випадків)

  • м'яка система в режимі реального часу не дає детермінованих гарантій, вона має на меті забезпечити найкращу можливу аналітичну задану ймовірнісну своєчасність та передбачуваність своєчасності, що можливо в сучасних динамічних обставинах, відповідно до конкретних критеріїв застосування. Очевидно важкий реальний час - простий особливий випадок м'якого реального часу. Очевидно, що аналітичні недетерміновані запевнення в реальному часі можуть бути дуже складними для надання, але є обов'язковими у найбільш поширених випадках у реальному часі (включаючи найнебезпечніші критичні для безпеки типи, наприклад, бойові), оскільки більшість випадків є динамічними, а не статичними.

На моєму веб-сайті real-time.org я детально обговорюю набагато більш точне обговорення реального часу, жорсткого реального часу, м'якого реального часу, передбачуваності, детермінізму та пов'язаних з ними тем .

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.