dМІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ.
Сибірський державний аерокосмічний університет ІМЕНІ АКАДЕМІКА М.Ф. Решетньова.
Реферат
з дисципліни "Системи реального часу"
На тему:
«Основні поняття і програмне забезпечення систем реального часу»
Виконав:
студент 2-го курсу
групи ІУТ-61
Нечаєв М. С.
Перевірив:
Котельникова С. В.
Красноярськ 2007
Зміст
Введення
1. Що таке реальний час
2. Класифікація систем реального часу
3. Ядра й операційні системи реального часу
3.1. Завдання, процеси, потоки
3.1.1. Переваги потоків
3.1.2. Недоліки потоків
3.2. Основні властивості завдань
3.3. Планування завдань
3.4. Синхронізація завдань
3.4.1. Пов'язані завдання
3.4.2. Загальні ресурси
3.4.3. Синхронізація з зовнішніми подіями
3.4.4. Синхронізація за часом
4. Тестування
5. Чи можна обійтися без ОС РВ?
Висновок
Список використаної літератури
Введення
Суверенністю можна сказати, що посилання на красиве словосполучення «реальний час» стали загальним місцем на різних семінарах, конференціях і в спеціалізованій пресі. З не меншою впевненістю можна сказати, що зміст цього терміна трактується фахівцями по-різному в залежності від області їх професійних інтересів, від того, є вони теоретиками або практиками, і навіть просто від особистого досвіду і кола спілкування. У цьому рефераті я спробував сконцентруватися на розгляді даного питання стосовно до цифрової обчислювальної техніки, використовуваної в системах управління та збору даних. Основна увага буде приділена програмному забезпеченню, тому що воно є найбільш слабкою ланкою в системах реального часу. Багатопроцесорні системи для простоти розглядатися не будуть. Реферат не претендує на вичерпне виклад предмета і є скоріше нотатками на тему основних понять і термінології в цій галузі.
1. Що таке реальний час
Якщо спробувати дати коротке визначення, то
1. Система називається системою реального часу, якщо правильність її функціонування залежить не тільки від логічної коректності обчислень, але і від часу, за який ці обчислення проводяться. Тобто для подій, що відбуваються в такій системі, то, КОЛИ ці події відбуваються, так само важливо, як логічна коректність самих подій.
2. Кажуть, що система працює в реальному часі, якщо її швидкодія адекватно швидкості перебігу фізичних процесів на об'єктах контролю або управління. Так як оточуючий нас світ дуже різноманітний, тут доречно додати, що маються на увазі саме ті процеси, які безпосередньо пов'язані з функціями, виконуваними конкретною системою реального часу. Тобто система управління повинна зібрати дані, провести їх обробку відповідно до заданих алгоритмів і видати керуючі впливу за такий проміжок часу, який забезпечує успішне вирішення поставлених перед системою завдань.
З наведених визначень випливає кілька цікавих висновків.
По-перше, практично всі системи промислової автоматизації є системами реального часу.
По-друге, приналежність системи до класу систем реального часу ніяк не пов'язана з її швидкодією. Наприклад, якщо ваша система призначена для контролю рівня грунтових вод, то навіть виконуючи вимірювання з періодичністю один раз за півгодини, вона буде працювати в реальному часі.
Вихідні вимоги до часу реакції системи та іншим часових параметрів визначаються або технічним завданням на систему, або просто логікою її функціонування. Наприклад, шахова програма, яка думає над кожним ходом більше року, працює явно не в реальному часі, так як шахіст швидше за все не доживе до кінця партії. Проте точне визначення «прийнятного часу реакції» не завжди є простим завданням, а в системах, де одним з ланок служить людина, піддається впливу суб'єктивних чинників. Втім, людина - це своєрідна обчислювальна машина, а ми домовилися багатопроцесорних конфігурацій не розглядати.
Інтуїтивно зрозуміло, що швидкодія системи реального часу має бути тим більше, чим більше швидкість протікання процесів на об'єкті контролю і управління. Щоб оцінити необхідну швидкодію для систем, що мають справу зі стаціонарними процесами, часто використовують теорему Котельникова, з якої випливає, що частота дискретизації сигналів повинна бути як мінімум в 2 рази вище граничної частоти їх спектру.
При роботі з широкосмуговими за своєю природою перехідними процесами (транзиент-аналіз) часто застосовують швидкодіючі АЦП з буферною пам'яттю, куди з необхідною швидкістю записується реалізація сигналу, яка потім аналізується і / або зареєстровано обчислювальною системою. При цьому потрібно закінчити всю необхідну обробку до наступного перехідного процесу, інакше інформація буде втрачена. Подібні системи іноді називають системами квазі-реального часу.
2. Класифікація систем реального часу
Прийнято розрізняти системи «жорсткого» та «м'якого» реального часу.
1. Системою «жорсткого» реального часу називається система, де нездатність забезпечити реакцію на будь-які події в заданий час є відмовою і веде до неможливості вирішення поставленого завдання. Наслідки таких відмов можуть бути різні, від протоки дорогоцінної вологи на лінії по розливу алкогольних напоїв до більш великих неприємностей, якщо, наприклад, вчасно не спрацювала система аварійних блокування атомного реактора. Багато теоретиків ставлять тут крапку, з чого випливає, що час реакції в «жорстких» системах може складати і секунди, і годинник, і тижня. Однак більшість практиків вважають, що час реакції в системах «жорсткого» реального часу має бути все-таки мінімальним. Йдучи на поводі у практиків, так і будемо вважати. Зрозуміло, однозначної думки про те, який час реакції властиво «жорстким» систем, немає. Більше того, зі збільшенням швидкодії мікропроцесорів цей час має тенденцію до зменшення, і якщо раніше в якості кордону називалося значення 1 мс, то зараз, як правило, називається час близько 100 мкс.
2. Точного визначення для «м'якого» реального часу не існує, тому будемо вважати, що сюди відносяться всі системи реального часу, але вони не попадають у категорію "жорстких". Так як система «м'якого» реального часу може не встигати ВСІ робити ЗАВЖДИ в заданий час, виникає проблема визначення критеріїв успішності (нормальності) її функціонування. Питання це зовсім не простий, тому що в залежності від функцій системи це може бути максимальна затримка у виконанні будь-яких операцій, середня своєчасність відпрацювання подій і т. п. Більше того, ці критерії впливають на те, який алгоритм планування завдань є оптимальним. Взагалі кажучи, системи «м'якого» реального часу опрацьовані теоретично далеко не до кінця.
3. Ядра й операційні системи реального часу
Щоб швидше перейти до справи, приймемо як очевидні наступні моменти:
1. Колись операційних систем зовсім не було.
2. Через деякий час після їх появи виник напрямок ОС РВ.
3. Всі ОС РВ є багатозадачними операційними системами. Завдання ділять між собою ресурси обчислювальної системи, в тому числі і процесорний час.
Чіткої межі між ядром (Kernel) і операційною системою немає. Розрізняють їх, як правило, по набору функціональних можливостей. Ядра надають користувачеві такі базові функції, як планування та синхронізація завдань, межзадачного комунікація, управління пам'яттю і т. п. Операційні системи на додаток до цього мають файлову систему, мережеву підтримку, інтерфейс з оператором та інші засоби високого рівня.
За своєю внутрішньою архітектурою ОС РВ можна умовно розділити на монолітні ОС, ОС на основі мікроядра і об'єктно-орієнтовані ОС. Графічно відмінності в цих підходах ілюструються малюнками 1, 2, 3. Переваги та недоліки різних архітектур досить очевидні, тому детально ми на них зупинятися не будемо.
Користувач, наляканий перспективою вивчати нову операційну систему, може тут цілком резонно запитати: «А чи не можна взагалі обійтися без всіх цих незрозумілих речей?»
Якщо відповідати на це питання однозначно, то так, МОЖНА. Однак відповідь на запитання про те, коли це ТРЕБА робити, залишається, звичайно, за користувачем. Матеріали цього реферату, можливо, дадуть деяку їжу до роздумів на цю тему.
3.1. Завдання, процеси, потоки
Існують різні визначення терміну «завдання» для багатозадачного ОС РВ. Ми будемо вважати завданням набір операцій (машинних інструкцій), призначений для виконання логічно закінченої функції системи. При цьому завдання конкурує з іншими завданнями за отримання контролю над ресурсами обчислювальної системи. Прийнято розрізняти два різновиди завдань: процеси і потоки. Процес є окремий завантаження програмний модуль (файл), який, як правило, під час виконання має в пам'яті свої незалежні області для коду та даних. На відміну від цього потоки можуть користуватися загальними ділянками коду й даних у рамках єдиного програмного модуля.
Гарним прикладом многопоточной програми є редактор тексту WORD, де в рамках однієї програми може одночасно відбуватися і набір тексту, і перевірка правопису.
3.1.1. Переваги потоків
1. Так як безліч потоків здатне розміщатися усередині одного ЕХЕ модуля, це дозволяє економити ресурси як зовнішньої, так і внутрішньої пам'яті.
2. Використання потоками загальної області пам'яті дозволяє ефективно організувати межзадачного обмін повідомленнями (досить передати вказівник на повідомлення). Процеси не мають загальної області пам'яті, тому ОС повинна або цілком скопіювати повідомлення з області пам'яті одного завдання в область пам'яті інший (що для великих повідомлень досить накладно), або передбачити спеціальні механізми, які дозволили б одну задачу отримати доступ до повідомлення з області пам'яті іншого завдання.
3. Як правило, контекст потоків менше, ніж контекст процесів, а значить, час перемикання між завданнями-потоками менше, ніж між завданнями-процесами.
4. Так як всі потоки, а іноді і саме ядро РВ розміщуються в одному ЕХЕмодуле, значно спрощується використання програм-відладчиків (debugger).
3.1.2. Недоліки потоків
1. Як правило, потоки не можуть бути завантажений динамічно. Щоб додати новий потік, необхідно провести відповідні зміни у вихідних текстах і перекомпілювати додаток. Процеси, на відміну від потоків, подгружаеми, що дозволяє динамічно змінювати функції системи в процесі її роботи. Крім того, так як процесам відповідають окремі програмні модулі, вони можуть бути розроблені різними компаніями, чим досягається додаткова гнучкість і можливість використання раніше напрацьованого ПЗ.
2. Те, що потоки мають доступ до областей даних один одного, може призвести до ситуації, коли некоректно працюючий потік здатний зіпсувати дані іншого потоку. На відміну від цього процеси захищені від взаємного впливу, а спроба запису у «не свою» пам'ять призводить, як правило, до виникнення спеціального переривання по обробці «виняткових ситуацій». Реалізація механізмів управління процесами і потоками, можливість їх взаємного співіснування та взаємодії визначаються конкретним ПЗ РВ.
3.2. Основні властивості завдань
Як правило, вся важлива, з точки зору операційної системи, інформація про завдання зберігається в уніфікованій структурі даних керуючому блоці (Task Control Block, TCB). У блоці зберігаються такі параметри, як ім'я та номер завдання, верхня і нижня межі стека, посилання на чергу повідомлень, статус завдання, пріоритет і т. п.
Пріоритет - це якесь ціле число, що привласнюється завданню і характеризує її важливість в порівнянні з іншими завданнями, виконуваними в системі. Пріоритет використовується в основному планувальником завдань для визначення того, яка з готових до роботи завдань повинна отримати управління. Розрізняють системи з динамічної та статичної пріоритетністю. У першому випадку пріоритет завдань може змінюватися в процесі виконання, в той час як у другому пріоритет завдань жорстко задається на етапі розробки або під час початкової конфігурації системи.
Контекст завдання - це набір даних, що містить всю необхідну інформацію для відновлення виконання завдання з того місця, де вона була раніше перервана. Часто контекст зберігається в ТСВ і включає в себе такі дані, як лічильник команд, вказівник стека, регістри СРU і FPU і т. п. Планувальник завдань у разі необхідності зберігає контекст поточної активної задачі і відновлює контекст завдання, призначеної до виконання. Таке переключення контекстів і є, по суті, основним механізмом ОС РВ при переході від виконання одного завдання до виконання іншої.
Стан (статус) завдання. З точки зору операційної системи, завдання може перебувати в декількох станах. Число і назва цих станів різняться від однієї ОС до іншої. Мабуть, найбільше число станів завдання визначено в мові Ada. Проте практично в будь-якій ОС РВ завантажена на виконання завдання може перебувати, принаймні, в трьох станах.
1. Активна завдання - це завдання, що виконується системою в поточній момент часу.
2. Готова завдання - це завдання, готова до виконання і чекає у планувальника своєї «черги».
3. Блокована завдання - це завдання, виконання якої припинено до настання певних подій. Такими подіями можуть бути звільнення необхідного завданню ресурсу, надходження очікуваного повідомлення, завершення інтервалу очікування і т. п.
Порожня завдання (Idle Task) - це завдання, що запускається самою операційною системою в момент ініціалізації і виконувана тільки тоді, коли в системі немає інших готових для виконання завдань. Порожня завдання запускається з найнижчим пріоритетом і, як правило, являє собою нескінченний цикл «нічого не робити». Наявність порожній завдання надає ОС зручний механізм відпрацювання ситуацій, коли немає жодної готової до виконання завдання.
Багаторазовий запуск завдань. Як правило, багатозадачні ОС дозволяють запускати кілька копій однієї і тієї ж задачі. При цьому для кожної такої копії створюється свій ТСВ і виділяється своя область пам'яті. З метою економії пам'яті може бути передбачено спільне використання одного і того ж виконуваного коду для всіх запущених копій. У цьому випадку програма повинна забезпечувати повторну входимость (реєнтерабельним). Крім того, програма не повинна використовувати тимчасові файли з фіксованими іменами і повинна коректно здійснювати доступ до глобальних ресурсів.
Реєнтерабельним (повторна входимость) означає можливість без негативних наслідків тимчасово перервати виконання якої-небудь функції або підпрограми, а потім викликати цю функцію чи підпрограму знову. Приватним проявом реєнтерабельним є рекурсія, коли тіло підпрограми містить виклик самої себе. Класичним прикладом нереентерабельной системи є DOS, а типовою причиною нереентерабельності служить використання глобальних змінних. Припустимо, що у нас є функція, що реалізує низкоуровневую запис на диск, і нехай вона використовує глобальну змінну write_sector, яка встановлюється відповідно до параметром, переданим цієї функції при виклику. Припустимо тепер, що Завдання А викликає цю функцію з параметром 3, тобто хоче записати дані в сектор номер 3. Припустимо, що коли змінна write_sector вже дорівнює 3, але сам запис ще не зроблена, виконання Завдання А переривається і починає виконуватися Завдання В, котораявизивает ту ж функцію, але з аргументом 10. Після того як запис в сектор номер 10 буде проведена, управління рано чи пізно повернеться до Завданню А, яка продовжить роботу з того ж місця. Однак, так як змінна write_sector має тепер значення 10, дані Завдання А, що призначалися для сектора номер 3, будуть замість цього записані в сектор № 10. З наведеного прикладу видно, що помилки, пов'язані з нереентерабельностью, важко виявити, а наслідки вони можуть викликати самі катастрофічні.
3.3. Планування завдань
Важливою частиною будь-якої ОС РВ є планувальник завдань. Незважаючи на те, що в різних джерелах він може називатися по-різному (диспетчер задач, супервізор і т. п.), його функції залишаються тими ж: визначити, яка із завдань повинна виконуватися в системі в кожен конкретний момент часу. Найпростішим методом планування, що не вимагає ніякого спеціального ПЗ та планувальника як такого, є використання циклічного алгоритму в стилі round robin:
Сибірський державний аерокосмічний університет ІМЕНІ АКАДЕМІКА М.Ф. Решетньова.
Реферат
з дисципліни "Системи реального часу"
На тему:
«Основні поняття і програмне забезпечення систем реального часу»
Виконав:
студент 2-го курсу
групи ІУТ-61
Нечаєв М. С.
Перевірив:
Котельникова С. В.
Красноярськ 2007
Зміст
Введення
1. Що таке реальний час
2. Класифікація систем реального часу
3. Ядра й операційні системи реального часу
3.1. Завдання, процеси, потоки
3.1.1. Переваги потоків
3.1.2. Недоліки потоків
3.2. Основні властивості завдань
3.3. Планування завдань
3.4. Синхронізація завдань
3.4.1. Пов'язані завдання
3.4.2. Загальні ресурси
3.4.3. Синхронізація з зовнішніми подіями
3.4.4. Синхронізація за часом
4. Тестування
5. Чи можна обійтися без ОС РВ?
Висновок
Список використаної літератури
Введення
Суверенністю можна сказати, що посилання на красиве словосполучення «реальний час» стали загальним місцем на різних семінарах, конференціях і в спеціалізованій пресі. З не меншою впевненістю можна сказати, що зміст цього терміна трактується фахівцями по-різному в залежності від області їх професійних інтересів, від того, є вони теоретиками або практиками, і навіть просто від особистого досвіду і кола спілкування. У цьому рефераті я спробував сконцентруватися на розгляді даного питання стосовно до цифрової обчислювальної техніки, використовуваної в системах управління та збору даних. Основна увага буде приділена програмному забезпеченню, тому що воно є найбільш слабкою ланкою в системах реального часу. Багатопроцесорні системи для простоти розглядатися не будуть. Реферат не претендує на вичерпне виклад предмета і є скоріше нотатками на тему основних понять і термінології в цій галузі.
1. Що таке реальний час
Якщо спробувати дати коротке визначення, то
1. Система називається системою реального часу, якщо правильність її функціонування залежить не тільки від логічної коректності обчислень, але і від часу, за який ці обчислення проводяться. Тобто для подій, що відбуваються в такій системі, то, КОЛИ ці події відбуваються, так само важливо, як логічна коректність самих подій.
2. Кажуть, що система працює в реальному часі, якщо її швидкодія адекватно швидкості перебігу фізичних процесів на об'єктах контролю або управління. Так як оточуючий нас світ дуже різноманітний, тут доречно додати, що маються на увазі саме ті процеси, які безпосередньо пов'язані з функціями, виконуваними конкретною системою реального часу. Тобто система управління повинна зібрати дані, провести їх обробку відповідно до заданих алгоритмів і видати керуючі впливу за такий проміжок часу, який забезпечує успішне вирішення поставлених перед системою завдань.
З наведених визначень випливає кілька цікавих висновків.
По-перше, практично всі системи промислової автоматизації є системами реального часу.
По-друге, приналежність системи до класу систем реального часу ніяк не пов'язана з її швидкодією. Наприклад, якщо ваша система призначена для контролю рівня грунтових вод, то навіть виконуючи вимірювання з періодичністю один раз за півгодини, вона буде працювати в реальному часі.
Вихідні вимоги до часу реакції системи та іншим часових параметрів визначаються або технічним завданням на систему, або просто логікою її функціонування. Наприклад, шахова програма, яка думає над кожним ходом більше року, працює явно не в реальному часі, так як шахіст швидше за все не доживе до кінця партії. Проте точне визначення «прийнятного часу реакції» не завжди є простим завданням, а в системах, де одним з ланок служить людина, піддається впливу суб'єктивних чинників. Втім, людина - це своєрідна обчислювальна машина, а ми домовилися багатопроцесорних конфігурацій не розглядати.
Інтуїтивно зрозуміло, що швидкодія системи реального часу має бути тим більше, чим більше швидкість протікання процесів на об'єкті контролю і управління. Щоб оцінити необхідну швидкодію для систем, що мають справу зі стаціонарними процесами, часто використовують теорему Котельникова, з якої випливає, що частота дискретизації сигналів повинна бути як мінімум в 2 рази вище граничної частоти їх спектру.
При роботі з широкосмуговими за своєю природою перехідними процесами (транзиент-аналіз) часто застосовують швидкодіючі АЦП з буферною пам'яттю, куди з необхідною швидкістю записується реалізація сигналу, яка потім аналізується і / або зареєстровано обчислювальною системою. При цьому потрібно закінчити всю необхідну обробку до наступного перехідного процесу, інакше інформація буде втрачена. Подібні системи іноді називають системами квазі-реального часу.
2. Класифікація систем реального часу
Прийнято розрізняти системи «жорсткого» та «м'якого» реального часу.
1. Системою «жорсткого» реального часу називається система, де нездатність забезпечити реакцію на будь-які події в заданий час є відмовою і веде до неможливості вирішення поставленого завдання. Наслідки таких відмов можуть бути різні, від протоки дорогоцінної вологи на лінії по розливу алкогольних напоїв до більш великих неприємностей, якщо, наприклад, вчасно не спрацювала система аварійних блокування атомного реактора. Багато теоретиків ставлять тут крапку, з чого випливає, що час реакції в «жорстких» системах може складати і секунди, і годинник, і тижня. Однак більшість практиків вважають, що час реакції в системах «жорсткого» реального часу має бути все-таки мінімальним. Йдучи на поводі у практиків, так і будемо вважати. Зрозуміло, однозначної думки про те, який час реакції властиво «жорстким» систем, немає. Більше того, зі збільшенням швидкодії мікропроцесорів цей час має тенденцію до зменшення, і якщо раніше в якості кордону називалося значення 1 мс, то зараз, як правило, називається час близько 100 мкс.
2. Точного визначення для «м'якого» реального часу не існує, тому будемо вважати, що сюди відносяться всі системи реального часу, але вони не попадають у категорію "жорстких". Так як система «м'якого» реального часу може не встигати ВСІ робити ЗАВЖДИ в заданий час, виникає проблема визначення критеріїв успішності (нормальності) її функціонування. Питання це зовсім не простий, тому що в залежності від функцій системи це може бути максимальна затримка у виконанні будь-яких операцій, середня своєчасність відпрацювання подій і т. п. Більше того, ці критерії впливають на те, який алгоритм планування завдань є оптимальним. Взагалі кажучи, системи «м'якого» реального часу опрацьовані теоретично далеко не до кінця.
3. Ядра й операційні системи реального часу
Щоб швидше перейти до справи, приймемо як очевидні наступні моменти:
1. Колись операційних систем зовсім не було.
2. Через деякий час після їх появи виник напрямок ОС РВ.
3. Всі ОС РВ є багатозадачними операційними системами. Завдання ділять між собою ресурси обчислювальної системи, в тому числі і процесорний час.
Чіткої межі між ядром (Kernel) і операційною системою немає. Розрізняють їх, як правило, по набору функціональних можливостей. Ядра надають користувачеві такі базові функції, як планування та синхронізація завдань, межзадачного комунікація, управління пам'яттю і т. п. Операційні системи на додаток до цього мають файлову систему, мережеву підтримку, інтерфейс з оператором та інші засоби високого рівня.
За своєю внутрішньою архітектурою ОС РВ можна умовно розділити на монолітні ОС, ОС на основі мікроядра і об'єктно-орієнтовані ОС. Графічно відмінності в цих підходах ілюструються малюнками 1, 2, 3. Переваги та недоліки різних архітектур досить очевидні, тому детально ми на них зупинятися не будемо.
Користувач, наляканий перспективою вивчати нову операційну систему, може тут цілком резонно запитати: «А чи не можна взагалі обійтися без всіх цих незрозумілих речей?»
Якщо відповідати на це питання однозначно, то так, МОЖНА. Однак відповідь на запитання про те, коли це ТРЕБА робити, залишається, звичайно, за користувачем. Матеріали цього реферату, можливо, дадуть деяку їжу до роздумів на цю тему.
3.1. Завдання, процеси, потоки
Існують різні визначення терміну «завдання» для багатозадачного ОС РВ. Ми будемо вважати завданням набір операцій (машинних інструкцій), призначений для виконання логічно закінченої функції системи. При цьому завдання конкурує з іншими завданнями за отримання контролю над ресурсами обчислювальної системи. Прийнято розрізняти два різновиди завдань: процеси і потоки. Процес є окремий завантаження програмний модуль (файл), який, як правило, під час виконання має в пам'яті свої незалежні області для коду та даних. На відміну від цього потоки можуть користуватися загальними ділянками коду й даних у рамках єдиного програмного модуля.
Гарним прикладом многопоточной програми є редактор тексту WORD, де в рамках однієї програми може одночасно відбуватися і набір тексту, і перевірка правопису.
3.1.1. Переваги потоків
1. Так як безліч потоків здатне розміщатися усередині одного ЕХЕ модуля, це дозволяє економити ресурси як зовнішньої, так і внутрішньої пам'яті.
2. Використання потоками загальної області пам'яті дозволяє ефективно організувати межзадачного обмін повідомленнями (досить передати вказівник на повідомлення). Процеси не мають загальної області пам'яті, тому ОС повинна або цілком скопіювати повідомлення з області пам'яті одного завдання в область пам'яті інший (що для великих повідомлень досить накладно), або передбачити спеціальні механізми, які дозволили б одну задачу отримати доступ до повідомлення з області пам'яті іншого завдання.
3. Як правило, контекст потоків менше, ніж контекст процесів, а значить, час перемикання між завданнями-потоками менше, ніж між завданнями-процесами.
4. Так як всі потоки, а іноді і саме ядро РВ розміщуються в одному ЕХЕмодуле, значно спрощується використання програм-відладчиків (debugger).
3.1.2. Недоліки потоків
1. Як правило, потоки не можуть бути завантажений динамічно. Щоб додати новий потік, необхідно провести відповідні зміни у вихідних текстах і перекомпілювати додаток. Процеси, на відміну від потоків, подгружаеми, що дозволяє динамічно змінювати функції системи в процесі її роботи. Крім того, так як процесам відповідають окремі програмні модулі, вони можуть бути розроблені різними компаніями, чим досягається додаткова гнучкість і можливість використання раніше напрацьованого ПЗ.
2. Те, що потоки мають доступ до областей даних один одного, може призвести до ситуації, коли некоректно працюючий потік здатний зіпсувати дані іншого потоку. На відміну від цього процеси захищені від взаємного впливу, а спроба запису у «не свою» пам'ять призводить, як правило, до виникнення спеціального переривання по обробці «виняткових ситуацій». Реалізація механізмів управління процесами і потоками, можливість їх взаємного співіснування та взаємодії визначаються конкретним ПЗ РВ.
3.2. Основні властивості завдань
Як правило, вся важлива, з точки зору операційної системи, інформація про завдання зберігається в уніфікованій структурі даних керуючому блоці (Task Control Block, TCB). У блоці зберігаються такі параметри, як ім'я та номер завдання, верхня і нижня межі стека, посилання на чергу повідомлень, статус завдання, пріоритет і т. п.
Пріоритет - це якесь ціле число, що привласнюється завданню і характеризує її важливість в порівнянні з іншими завданнями, виконуваними в системі. Пріоритет використовується в основному планувальником завдань для визначення того, яка з готових до роботи завдань повинна отримати управління. Розрізняють системи з динамічної та статичної пріоритетністю. У першому випадку пріоритет завдань може змінюватися в процесі виконання, в той час як у другому пріоритет завдань жорстко задається на етапі розробки або під час початкової конфігурації системи.
Контекст завдання - це набір даних, що містить всю необхідну інформацію для відновлення виконання завдання з того місця, де вона була раніше перервана. Часто контекст зберігається в ТСВ і включає в себе такі дані, як лічильник команд, вказівник стека, регістри СРU і FPU і т. п. Планувальник завдань у разі необхідності зберігає контекст поточної активної задачі і відновлює контекст завдання, призначеної до виконання. Таке переключення контекстів і є, по суті, основним механізмом ОС РВ при переході від виконання одного завдання до виконання іншої.
Стан (статус) завдання. З точки зору операційної системи, завдання може перебувати в декількох станах. Число і назва цих станів різняться від однієї ОС до іншої. Мабуть, найбільше число станів завдання визначено в мові Ada. Проте практично в будь-якій ОС РВ завантажена на виконання завдання може перебувати, принаймні, в трьох станах.
1. Активна завдання - це завдання, що виконується системою в поточній момент часу.
2. Готова завдання - це завдання, готова до виконання і чекає у планувальника своєї «черги».
3. Блокована завдання - це завдання, виконання якої припинено до настання певних подій. Такими подіями можуть бути звільнення необхідного завданню ресурсу, надходження очікуваного повідомлення, завершення інтервалу очікування і т. п.
Порожня завдання (Idle Task) - це завдання, що запускається самою операційною системою в момент ініціалізації і виконувана тільки тоді, коли в системі немає інших готових для виконання завдань. Порожня завдання запускається з найнижчим пріоритетом і, як правило, являє собою нескінченний цикл «нічого не робити». Наявність порожній завдання надає ОС зручний механізм відпрацювання ситуацій, коли немає жодної готової до виконання завдання.
Багаторазовий запуск завдань. Як правило, багатозадачні ОС дозволяють запускати кілька копій однієї і тієї ж задачі. При цьому для кожної такої копії створюється свій ТСВ і виділяється своя область пам'яті. З метою економії пам'яті може бути передбачено спільне використання одного і того ж виконуваного коду для всіх запущених копій. У цьому випадку програма повинна забезпечувати повторну входимость (реєнтерабельним). Крім того, програма не повинна використовувати тимчасові файли з фіксованими іменами і повинна коректно здійснювати доступ до глобальних ресурсів.
Реєнтерабельним (повторна входимость) означає можливість без негативних наслідків тимчасово перервати виконання якої-небудь функції або підпрограми, а потім викликати цю функцію чи підпрограму знову. Приватним проявом реєнтерабельним є рекурсія, коли тіло підпрограми містить виклик самої себе. Класичним прикладом нереентерабельной системи є DOS, а типовою причиною нереентерабельності служить використання глобальних змінних. Припустимо, що у нас є функція, що реалізує низкоуровневую запис на диск, і нехай вона використовує глобальну змінну write_sector, яка встановлюється відповідно до параметром, переданим цієї функції при виклику. Припустимо тепер, що Завдання А викликає цю функцію з параметром 3, тобто хоче записати дані в сектор номер 3. Припустимо, що коли змінна write_sector вже дорівнює 3, але сам запис ще не зроблена, виконання Завдання А переривається і починає виконуватися Завдання В, котораявизивает ту ж функцію, але з аргументом 10. Після того як запис в сектор номер 10 буде проведена, управління рано чи пізно повернеться до Завданню А, яка продовжить роботу з того ж місця. Однак, так як змінна write_sector має тепер значення 10, дані Завдання А, що призначалися для сектора номер 3, будуть замість цього записані в сектор № 10. З наведеного прикладу видно, що помилки, пов'язані з нереентерабельностью, важко виявити, а наслідки вони можуть викликати самі катастрофічні.
3.3. Планування завдань
Важливою частиною будь-якої ОС РВ є планувальник завдань. Незважаючи на те, що в різних джерелах він може називатися по-різному (диспетчер задач, супервізор і т. п.), його функції залишаються тими ж: визначити, яка із завдань повинна виконуватися в системі в кожен конкретний момент часу. Найпростішим методом планування, що не вимагає ніякого спеціального ПЗ та планувальника як такого, є використання циклічного алгоритму в стилі round robin:
void main (void)
{
for (;;) {
task0 ();
task1 ();
task2 ();
/ * І т. д. * /
}
}
Кожна «завдання», що представляє собою окрему підпрограму, виконується циклічно. При цьому треба дотримуватися наступних правил:
1. Підпрограми не повинні містити циклів очікування в стилі
while (TRUE) {
if (switch_up ()) {
lamp_off ();
break;
}
}
2. Підпрограми повинні виконувати свою роботу як можна швидше, щоб дати можливість працювати наступного підпрограмі.
3. При необхідності підпрограма може зберігати своє оточення і поточні результати, щоб у наступному циклі поновити роботу з того ж місця. Можна відзначити наступні переваги циклічного алгоритму.
1. Простота використання та прозорість для розуміння.
2. Якщо виключити з розгляду переривання, система повністю детермінована. Завдання завжди викликаються в одній і тій же послідовності, що дозволяє досить просто зробити аналіз "найгіршого випадку» і обчислити максимальну затримку.
3. Мінімальні розміри коду і даних. Крім того, на відміну від алгоритмів з витісненням, для всіх задач необхідний тільки один стек.
4. Відсутні помилки, зумовлені «гонками».
До недоліків циклічного алгоритму можна віднести відсутність пріоритетності і черг. До того ж завдання викликаються незалежно від того, чи повинні вони в даний момент чтолибо робити чи ні, а на прикладного програміста лягає максимальна відповідальність за працездатність системи.
Перейдемо тепер до другого широко використовуваному алгоритму планування. Мова піде про режим поділу часу. Існують різні реалізації в рамках цього алгоритму, і деякі західні фахівці навіть розрізняють такі загалом ідентичні для нас поняття, як timeslicing і time-sharing. Як правило, алгоритм реалізується наступним чином: кожного завдання відводиться певна кількість квантів часу (зазвичай кратне 1 мс), протягом яких завдання може монопольно займати процесорний час. Після того як заданий інтервал часу минає, управління передається наступній готової до виконання задачі, що має найвищий пріоритет. Та, у свою чергу, виконується протягом відведеного для неї проміжку часу, після чого все повторюється в стилі round robin. Легко помітити, що такий алгоритм роботи може призвести до певних проблем. Уявімо, що в системі працюють 7 завдань, 3 з яких мають високий пріоритет, а 4 - низький. Низькопріоритетні завдання можуть ніколи не отримати управління, оскільки три високопріоритетні завдання будуть ділити все процесорний час між собою. Єдину можливість для низькопріоритетних завдань отримати управління надає ситуація, коли всі високопріоритетні завдання знаходяться у блокованому стані.
Для вирішення цієї проблеми застосовується прийом, що одержав назву рівнодоступність (fairness). При цьому реалізується принцип адаптивної пріоритетності, коли пріоритет завдання, що виконується занадто довго, поступово зменшується, дозволяючи менш пріоритетним завданням отримати свою частку процесорного часу. Рівнодоступність застосовується головним чином в багатокористувацьких системах і рідко застосовується в системах реального часу.
Кооперативна багатозадачність - це ще один алгоритм перемикання завдань, з яким широкі маси комп'ютерної громадськості знайомі по операційній системі Windows 3.х. Завдання, що отримала управління, виконується до тих пір, поки вона сама за своєю ініціативою не передасть управління іншої задачі. По суті це продовження ідеології round robin, і немає потреби пояснювати, чому алгоритм кооперативної багатозадачності в чистому вигляді мало застосовується в системах реального часу.
Пріоритетна багатозадачність з витісненням - це, мабуть, найбільш часто використовується в ОС РВ принцип планування. Основна ідея полягає в тому, що високопріоритетних завдання, як тільки для неї з'являється робота, негайно перериває (витісняє) низькопріоритетних. Іншими словами, якщо яка-небудь задача переходить в стан готовності, вона негайно отримує управління, якщо поточна активна задача має більш низький пріоритет. Таке «витіснення» відбувається, наприклад, коли високопріоритетних завдання отримала очікуване повідомлення, звільнився запитаний нею ресурс, відбулося пов'язане з нею зовнішня подія, вичерпався заданий інтервал часу і т. п.
Закінчуючи розгляд основних принципів планування завдань, необхідно відзначити, що тема ця далеко не вичерпана. Діапазон систем реального часу досить широкий, починаючи від повністю статичних систем, де всі завдання і їх пріоритети заздалегідь визначені, до динамічних систем, де набір виконуваних завдань, їх пріоритети і навіть алгоритми планування можуть змінюватися в процесі функціонування. Існують, наприклад, системи, де кожна окрема задача може брати участь в будь-якому з трьох алгоритмів планування або їх комбінації (витіснення, поділ часу, кооперативность).
У загальному випадку алгоритми планування повинні відповідати критеріям оптимальності функціонування системи. Однак, якщо для систем «жорсткого» реального часу такий критерій очевидний: «ЗАВЖДИ і ВСЕ робити вчасно», то для систем «м'якого» реального часу це може бути, наприклад, мінімальна «максимальне запізнювання» або середньозважена своєчасність завершення операцій. У залежності від критеріїв оптимальності можуть застосовуватися алгоритми планування завдань, відмінні від розглянутих. Наприклад, може виявитися, що планувальник повинен аналізувати момент видачі критичних за часом керуючих впливів і запускати на виконання те завдання, яке відповідає за найближчі з них (алгоритм earliest deadline first, EDF).
Необхідно відзначити, що в одній обчислювальній системі можуть одночасно співіснувати завдання і «жорсткого», і «м'якого» реального часу, і що тільки одна з цих завдань, що володіє найвищим пріоритетом, може бути по-справжньому детермінованою.
Не варто особливо захоплюватися пріоритетами. Якщо система нормально працює, коли всі завдання мають однаковий пріоритет, то й слава Богу. Якщо ні, то можна привласнити високий пріоритет «критичної» завданню, і низький пріоритет всім іншим. Якщо у вас більше однієї «критичної» завдання, при недостатньому швидкодії системи має сенс розглянути багатопроцесорну конфігурацію або, відмовившись від ПО РВ, перейти до простого циклічного алгоритму.
Як правило, розробники намагаються звести свою систему реального часу до найбільш простим конфігурацій, характерним для систем «жорсткого» реального часу, іноді навіть на шкоду ефективності використання обчислювальних ресурсів. Причина зрозуміла: складні динамічні системи дуже важко аналізувати і налагоджувати, тому краще заплатити за більш потужний процесор, ніж мати в майбутньому проблеми через непередбачуване поведінки системи. У зв'язку з цим більшість існуючих систем реального часу являють собою статичні системи з фіксованими пріоритетами. Часто в системі реалізується кілька «режимів» роботи, кожен з яких має свій набір виконуваних завдань із заздалегідь заданими пріоритетами. Значна частина особливо відповідальних систем, як і раніше реалізується без застосування комерційних ОС РВ взагалі.
3.4. Синхронізація завдань
Хоча кожна завдання в системі, як правило, виконує яку-небудь окрему функцію, часто виникає необхідність в узгодженості (синхронізації) дій, що виконуються різними завданнями. Така синхронізація необхідна, в основному, в наступних випадках.
1. Функції, що виконуються різними завданнями, пов'язані один з одним. Наприклад, якщо одне завдання готує вихідні дані для іншого, то остання не виконується до тих пір, поки не отримає від першого завдання відповідного повідомлення. Одна з варіацій в цьому випадку - це коли завдання за певних умов породжує одну або декілька нових завдань.
2. Необхідно впорядкувати доступ декількох завдань до ресурсу.
3. Необхідна синхронізація завдання із зовнішніми подіями. Як правило, для цього використовується механізм переривань, з яким.
4. Необхідна синхронізація завдання за часом. Діапазон різних варіантів в цьому випадку досить широкий, від прив'язки моменту видачі будь-якого впливу до точного астрономічному часу до простої затримки виконання завдання на певний інтервал часу. Для вирішення цих питань у кінцевому рахунку використовуються спеціальні апаратні засоби, звані таймером.
Давайте розглянемо всі чотири випадки більш докладно.
3.4.1. Пов'язані завдання
Взаємне узгодження завдань за допомогою повідомлень є одним з найважливіших принципів операційних систем реального часу. Способи реалізації межзадачного обміну відрізняються великою різноманітністю, що не в останню чергу призводить до великої кількості термінів у цій галузі. Можна зустріти такі поняття, як повідомлення (message), поштовий ящик (mail box), сигнал (signal), подія (event), проксі (proxy) і т. п. Якщо, читаючи опис якої-небудь ОС РВ, ви зустрінете вже знайому назву, не поспішайте робити висновки. Навіть один і той же термін може для різних ОС РВ позначати різні речі. Щоб не заплутатися, ми будемо надалі називати повідомленнями будь-який механізм явною передачі інформації від однієї задачі до іншої (такі об'єкти, як семафори, можна віднести до механізму неявній передачі повідомлень).
Обсяг інформації, переданої в повідомленнях, може змінюватися від 1 біта до всієї вільної ємності пам'яті вашої системи. У багатьох ОС РВ компоненти операційної системи, так само як і користувальницькі завдання, які спроможні приймати і передавати повідомлення. Повідомлення можуть бути асинхронними і синхронними. У першому випадку доставка повідомлень завданню проводиться після того, як вона в плановому порядку отримає управління, а в другому випадку циркуляція повідомлень безпосередньо впливає на планування завдань. Наприклад, завдання, що послала яке-небудь повідомлення, негайно блокується, якщо для продовження роботи їй необхідно дочекатися відповіді, або якщо низькопріоритетних завдання шле найпріорітетніше завданню повідомлення, якого остання очікує, то високопріоритетних завдання, якщо, звичайно, використовується пріоритетна багатозадачність з витісненням, негайно отримає управління.
Іноді повідомлення передаються через відведений для цього буфер певного розміру («поштова скринька»). При цьому, як правило, нове повідомлення затирає старе, навіть якщо останнє не було опрацьовано.
Однак найбільш часто використовується принцип, коли кожна задача має свою чергу повідомлень, в кінець якої ставиться всяке знову отримане повідомлення. Стандартний принцип обробки черги повідомлень за принципом «першим увійшов, першим вийшов» (FIFO) не завжди оптимально відповідає поставленому завданню. У деяких ОС РВ передбачається така можливість, коли повідомлення від найпріорітетніше завдання обробляється в першу чергу (в цьому випадку говорять, що повідомлення успадковує пріоритет послала його завдання).
Іноді корисним виявляється безпосереднє управління пріоритетом повідомлень. Уявімо, що завдання послала сервера (драйвера) принтера кілька повідомлень, що містять дані для друку. Якщо тепер завдання хоче скасувати всю друк, їй треба послати відповідне повідомлення з більш високим пріоритетом, щоб воно стало в чергу попереду усіх набраних раніше завдань на друк. Повідомлення може містити як самі дані, призначені для передачі, так і покажчик на такі дані. В останньому випадку обмін може здійснюватися за допомогою поділюваних областей пам'яті, поділюваних файлів і т. п.
3.4.2. Загальні ресурси
Важко переоцінити важливість правильної організації взаємодії різних завдань при доступі до загальних ресурсів. Доброю аналогією може служити обід в багатодітній селянській родині минулого століття. Їдоках (завданням) не дозволялося одночасно лізти ложками в загальну миску (ресурс). Порушники порядку могли отримати від батька сімейства (супервізора) ложкою по лобі.
Ресурс - це загальний термін, що описує фізичний пристрій або область пам'яті, які можуть одночасно використовуватися тільки одним завданням. Процесорний час теж являє собою своєрідний конкурентно використовуваний ресурс обчислювальної системи. Прикладом фізичних пристроїв можуть служити клавіатура, дисплей, дисковий накопичувач, принтер і т. п. Уявімо, наприклад, що кілька завдань намагаються одночасно виводити дані на принтер. На роздруківці в результаті нічого, крім дивною мішанини символів, ми не побачимо. В якості іншого прикладу розглянемо ситуацію, коли в бортовому комп'ютері мирно літака МІГ-29 серед інших працюють два завдання. Одна з них, взаємодіючи з радіолокаційною системою, видає видалення і напрямок до мети, а інше завдання використовує ці дані для пуску ракет класу «повітря-повітря». Не виключено, що перше завдання, записавши в глобальну структуру даних видалення до мети, буде перервана другим завданням, не встигнувши записати туди напрямок до мети. У результаті друга задача вважає з цієї структури помилкові дані, що може призвести до невдалого пуску з усіма наслідками, що випливають звідси неприємними наслідками. Перервіть перше завдання трохи пізніше, і все було б нормально. Згадані тут проблеми обумовлені времязавісімимі помилками (time dependent error), або «гонками» і характерні для багатозадачних ОС, що застосовують алгоритми планування з витісненням (до речі, системи з розділенням часу також відносяться до категорії «витісняють»).
Наведений приклад показує, що помилки, зумовлені «гонками»,
а) характерні для роботи з будь-якими ресурсами, доступ до яких мають кілька завдань, і б) відбуваються тільки в результаті збігу певних умов, а тому з працею виявляються на етапі налагодження. Ось можливі шляхи вирішення проблеми.
1. Не використовувати алгоритми планування завдань з витісненням. Це рішення, щоправда, не завжди прийнятно.
2. Використовувати спеціальний сервер ресурсу, тобто завдання, відповідальну за упорядкування доступу до ресурсу. У цьому випадку запит на зміну значення глобальних даних надсилається цього сервера у вигляді повідомлення. Аналогічний підхід застосуємо і для фізичних пристроїв. Так, наприклад, завдання може послати дані на друк у вигляді повідомлення, направленого до сервера принтера.
3. Заборонити переривання на час доступу до даних, що розділяються. Кардинальне рішення, яке, втім, не вітається в системах реального часу.
4. Використовувати для упорядкування доступу до глобальних даними семафори. Найбільш часто застосовується рішення, яке, втім, може привести в деяких випадках до «інверсії пріоритетів».
Останній пункт стоїть прокоментувати докладніше, оскільки поняття «семафор» зустрічається вперше.
Семафор - це якраз той засіб, який часто використовується для синхронізації доступу до ресурсів. У найпростішому випадку семафор представляє собою байтове змінну, приймаючу значення 0 або 1. Завдання, перед тим як використовувати ресурс, захоплює семафор, після чого інші завдання, які бажають використовувати той самий ресурс, повинні чекати, поки семафор (ресурс) звільниться. Існують також так звані рахункові семафори, де семафор представляє собою лічильник. Нехай до системи підключено три принтера. Семафор, що відповідає за доступ до функцій друку, ініціалізується із значенням 3, а потім кожного разу, коли яка-небудь задача запитує семафор для здійснення друку, його значення зменшується на 1. Після друку завдання звільняє семафор, в результаті чого значення останнього збільшується на 1. Якщо поточне значення семафора дорівнює 0, то ресурс вважається недоступним, і завдання, що запитують друк, повинні чекати, поки не звільниться хоча б один принтер. Таким чином може здійснюватися синхронізація доступу безлічі завдань до групи з 3 принтерів. Так як за своєю суттю семафор також являє собою глобальну змінну, всі неприємності, які згадувалися раніше в зв'язку з літаком МІГ-29, по ідеї, повинні чекати нас і тут. Однак, так як робота з семафорами відбувається на рівні системних викликів, програміст може бути впевнений, що розробники операційної системи про все заздалегідь подбали.
Перейнявшись свідомістю того, наскільки небезпечно змінювати глобальні змінні в умовах, коли всі навколо так і норовлять одне одного витіснити, ділянки коду програм, де відбувається звернення до ресурсів, називаються критичними секціями.
Так як процеси звичайно не мають доступу до даних один одного, а ресурси фізичних пристроїв, як правило, управляються спеціальними завданнями-серверами (драйверами), найбільш типова ситуація, коли «гонки» за доступ до глобальних змінних влаштовують різні потоки, що виконуються в рамках одного програмного модуля. Для того щоб гарантувати, що критична секція коду виконується в кожний момент часу лише одним потоком, використовують механізм взаємовиключення доступу, або просто мутексов (Mutual Exclusion Locks, Mutex). Практично мутекс представляє собою різновид семафора, який сигналізує іншим потокам, що критична секція коду ким-то вже виконується.
Критична секція, яка використовує мутекс, повинна мати певні суффіксную і префіксной частини. Наприклад:
int global_counter;
void main (void)
{
mutex_t mutex;
(
/ * І все це лише для того, щоб збільшити глобальну змінну на одиницю .* /
mutex_init (& mutex, USYNC, NULL);
mutex_lock (& mutex);
global_counter + +;
mutex_unlock (& mutex);
}
Якщо мутекс захоплений, то потік, який намагається увійти у критичну секцію, блокується. Після того як мутекс звільняється, один з стоять у черзі потоків (якщо такі накопичилися) розблокується і отримує можливість доступу до глобального ресурсу.
Думаю, на цьому розгляд засобів синхронізації доступу до загальних ресурсів можна закінчити, хоча, звичайно, безліч тим залишилося за дужками. Наприклад, в WIN32 використовується, в числі іншого, спеціальний різновид мутексов під назвою Critical Section Object. Необхідно також пам'ятати, що, крім ОС, що мають WIN32 або POSIX API, існує велика кількість ні з чим не сумісних ОС, тому наявність коштів синхронізації та особливості їх реалізації повинні розглядатися окремо для кожної конкретної ОС РВ.
А ось можливі неприємності у боротьбі за ресурси.
Смертельний захоплення (Deadlock). У народі побічні прояви цієї ситуації називаються більш прозаїчно - «зациклення» або «зависання». А причина цього може бути досить проста - «завдання не поділили ресурси». Нехай, наприклад, Завдання А захопила ресурс клавіатури і чекає, коли звільниться ресурс дисплея, а в цей час Задача також хоче поспілкуватися з користувачем і, встигнувши захопити ресурс дисплея, чекає тепер, коли звільниться клавіатура. Так і будуть завдання чекати один одного до другого потопу, а користувач буде в цей час дивитися на порожній екран і лаяти останніми словами яйцеголових програмістів, які не змогли зробити нормально працюючу систему. У таких випадках рекомендується дотримуватися тактики «або все, або нічого». Іншими словами, якщо завдання не змогла отримати всі необхідні для подальшої роботи ресурси, вона повинна звільнити все, що вже захоплено, і, як кажуть, «зайти через півгодини». Іншим рішенням, яке вже згадувалося, є використання серверів ресурсів.
Інверсія пріоритетів (Priority inversion). Як вже зазначалося, алгоритми планування завдань (управління доступом до процесорного часу) повинні знаходитися у відповідності з методами управління доступом до інших ресурсів, а всі разом - відповідати критеріям оптимального функціонування системи. Ефект інверсії пріоритетів є наслідком порушення гармонії в цій області. Ситуація тут схожа на «смертельний захоплення», проте сюжет закручений ще більше лихо. Уявімо, що у нас є високопріоритетних Завдання А, среднепріорітетная Завдання В і низькопріоритетних Завдання С. Нехай в початковий момент часу Завдання А і В блоковані в очікуванні якої-небудь зовнішньої події. Припустимо, що отримала в результаті цього управління Завдання З захопила Семафор А, але не встигла вона його віддати, як була перервана Завданням А. У свою чергу, Завдання А при спробі захопити Семафор А буде блокована, тому що цей семафор вже захоплений Завданням С. Якщо до цього часу Завдання В знаходиться в стані готовності, то управління після цього отримає саме вона, як має більш високий, ніж у Завдання С, пріоритет. Тепер Завдання В може займати процесорний час, поки їй не набридне, а ми отримуємо ситуацію, коли високопріоритетних Завдання А не може функціонувати через те, що необхідний їй ресурс зайнятий низькопріоритетний Завданням С.
3.4.3. Синхронізація з зовнішніми подіями
Відомо, що застосування апаратних переривань є більш ефективним методом взаємодії із зовнішнім світом, ніж метод опитування. Розробники систем реального часу намагаються використати цей факт в повній мірі. При цьому можна простежити такі тенденції:
1. Прагнення забезпечити максимально швидку і детерміновану реакцію системи на зовнішню подію.
2. Намагання домогтися мінімально можливих періодів часу, коли в системі заборонені переривання.
3. Підпрограми обробки переривань виконують мінімальний обсяг функцій за максимально короткий час. Це обумовлено декількома причинами. По-перше, не всі ОС РВ забезпечують можливість «витіснення» під час обробки підпрограм переривання. По-друге, пріоритети апаратних переривань не завжди відповідають пріоритетам завдань, з якими вони пов'язані. По-третє, затримки з обробкою переривань можуть призвести до втрати даних.
Як правило, закінчивши елементарно необхідні дії, підпрограма обробки переривань генерує в тій або іншій формі повідомлення для завдання, з якою це переривання пов'язано, і негайно повертає управління. Якщо це повідомлення перевело завдання в розряд готових до виконання, планувальник в залежності від використовуваного алгоритму і пріоритету завдання приймає рішення про те, чи необхідно ні негайно передати управління отримала повідомлення завданню. Зрозуміло, це всього лише один з можливих сценаріїв, так як кожна ОС РВ має свої особливості при обробці переривань. Крім того, свою специфіку може накладати використовувана апаратна платформа.
3.4.4. Синхронізація за часом
Зовсім не так давно (років 20 тому) апаратні засоби, що відповідають в обчислювальних системах за службу часу, були абсолютно не розвинені. У ті вікопомні часи вважалося достатнім, якщо в системі генерувалося переривання з частотою мережі змінного струму. Ті ж, хто не знав, що частота мережі в США 60 Гц, а не 50, як у нас, постійно дивувалися тому, що системний час у RSX-11M ніколи не буває правильним. Програмісти для отримання затримок за часом часто використовували програмні цикли очікування і, зрозуміло, користувачі таких програм отримували масу сюрпризів при спробі їх перенесення на наступне покоління комп'ютерів з більш високими тактовими частотами. Слава Богу (або науково-технічному прогресу), зараз будь-який мало-мальськи пристойний комп'ютер має годинник / календар з батарейною підтримкою і багатофункціональний таймер (а то й кілька) з роздільною здатністю до одиниць мікросекунд.
Як правило, в ОС РВ задається еталонний інтервал (квант) часу, який іноді називають тиком (Tick) і який використовується в якості базової одиниці виміру часу. Розмірність цієї одиниці для різних ОС РВ може бути різною, як, втім, різними можуть бути набір функцій і механізми взаємодії з таймером. Функції по роботі з таймером використовують для призупинення виконання завдання на якийсь час, завдання для запуску в певний час, для відносної синхронізації декількох завдань за часом і т. п. Якщо в програмі для ОС РВ ви побачите операнд delay (50), то , швидше за все, це означає, що в цьому місці завдання має перерватися (блокуватися), а через 50 мс відновити своє виконання, а точніше, перейти в стан готовності. Весь цей час процесор не простоює, а вирішує інші завдання, якщо такі є. Безліч завдань одночасно можуть запросити сервіс таймера, тому якщо для кожного такого запиту використовується елемент в таблиці тимчасових інтервалів, то накладні витрати системи з обробки переривань від апаратного таймера ростуть пропорційно розмірності цієї таблиці і можуть стати неприпустимими. Для вирішення цієї проблеми можна замість таблиці використовувати зв'язний список та алгоритм так званого диференціального таймера, коли під час кожного тика зменшується тільки один лічильник інтервалу часу.
Для точної синхронізації таймера обчислювальної системи з астрономічним часом можуть застосовуватися спеціальний годинник з підстроюванням за радіосигналами точного часу або навігаційні приймачі GPS, які дозволяють скористатися атомним годинником на борту орбітальних космічних апаратів, запущених за програмою Navstar.
4. Тестування
Перш ніж встановлювати вашу систему реального часу на не менш реальному об'єкті, рекомендується перевірити її працездатність за допомогою інтенсивних тестів. Це особливо важливо для складних динамічних систем. Під час такого тестування бажано змоделювати найбільш неприємні і «важкі» режими роботи, аварійні ситуації і т. п. При умоглядному аналізі простих систем слід обережно ставитися до рекламної інформації розробників ОС РВ, які з комерційних міркувань показують, як правило, параметри для «кращого випадку ». Наприклад, якщо мова йде про максимальне часу обробки переривання, необхідно в першу чергу зрозуміти, а що, власне, мається на увазі під цим часом:
а) час від виникнення запиту на переривання до передачі керування по векторі переривання;
б) або включаючи час збереження контексту поточного завдання та передачі управління підпрограмі обробки переривання;
в) або додатково до цього ще й час до завершення підпрограми обробки переривання і передачі повідомлення пов'язаної з перериванням завданню;
г) або додатково до цього час до моменту, коли це завдання нарешті отримає управління (у припущенні, що вона є найбільш пріоритетною) і почне реальну обробку події.
Безвідносно до того, який варіант розглядається, необхідно пам'ятати, що
1) якщо поряд з розробленими вами програмами використовується програмне забезпечення третіх фірм, ви не застраховані від того, що там не зустрінуться ділянки коду, де переривання заборонені;
2) практично будь-яка ОС РВ має у своїх надрах ділянки такого коду. Нам залишається тільки сподіватися, що розробники ОС намагалися робити їх якомога менше;
3) всі ядро ОС РВ або його ділянки можуть бути «не витісняє»;
4) інтелектуальні контролери введення / виводу типу SCSI можуть ініціювати в системі різні службові операції, які здатні позначитися на її характеристиках;
5) багато чого залежить від вживаної системи кешування. Тому, якщо ваше подія відбулася в «невідповідний» час, реальні показники швидкодії можуть сильно відрізнятися від рекламованих.
5. Чи можна обійтися без ОС РВ?
Як будь-яку обчислювальну систему можна створити тільки з елементів 2И! НЕ, так і все, що може робити ОС РВ, реалізоване і без неї. Тим не менш, давайте все-таки спробуємо розібратися, коли ОС РВ реально потрібна, а коли ні. Припустимо, нам треба не рідше 10 разів на секунду опитати три перемикачі і залежно від їх положення включити або виключити відповідний насос.
Програма може виглядати наступним чином:
void main (void)
{
int i;
for (;;) {
for (i = 0; i <3; i + +) {
if (switch_was_changed (i)) change_Pump (i);
}
}
}
Зауважте, що ніяких перевірок з дня немає, тому що навіть самі повільні процесори можуть сканувати перемикачі частіше 10 разів на секунду. Програма адекватна поставленій задачі. Якщо потрібно опитувати перемикачі рівно 10 разів на секунду, програма може бути змінена:
for (;;) {
if (100msec_passed) {
for (i = 0; i <3; i + +) {
if (switch_was_changed (i) change_Pump (i);
}
100msec_passed = 0;
}
}
Глобальна змінна 100msec_passed встановлюється в «1» кожні 100 мс за допомогою підпрограми обробки переривань від таймера. Тепер припустимо, що нам додатково потрібно кожні 200 мс вимірювати тиск і відкривати вентиль, якщо тиск більше 20 атм. Якщо при відкритому вентилі тиск падає нижче 15 атм, вентиль необхідно закрити. Для виконання цього завдання в тіло циклу може бути доданий наступний фрагмент:
if (200msec_passed) {
switch (valve_status) {
case CLOSED:
if (divssure_value ()> 20) {
open_valve (); valve_status = OPEN;
}
case OPEN:
if (divssure_value () <15) {
close_valve (); valve_status = CLOSED;
}
}
200msec_passed = 0;
}
Глобальна змінна 200msec_passed встановлюється в 1 кожні 200 мс. Оскільки тіло циклу for (;;) стало великим, зручно винести функції в окремі підпрограми і переписати основну програму наступним чином: for (;;) {process_pump_switches (); process_divssure_regulation ();} У міру того як додаються нові «завдання», їх можна оформляти окремими підпрограмами і включати відповідні виклики в тіло головної програми. Однак у міру додавання нових функцій час виконання основного циклу збільшується, в результаті чого може наступити момент, коли вимога про сканування перемикачів 10 разів на секунду перестане виконуватися. Давайте ще трохи ускладнити завдання. Нехай система має відображати тренди на основі пакетів даних, одержуваних через швидкодіючий послідовний порт. У цьому випадку основна програма може виглядати як
for (;;) {
process_pump_switches ();
process_divssure_regulation ();
show_trend ();
}
Якщо функція show_trend викликається з запізненням, то пакет даних може бути втрачений. Рішенням цієї проблеми може бути винос комунікаційних функцій з show_trend і організація черги, куди при обробці переривань послідовного порту поміщається черговий заповнений пакет для подальшої обробки за допомогою show_trend.
Наведений тут приклад ілюструє циклічний (round robin) механізм виконання завдань, цілком відповідний для багатьох застосувань. Однак цей же приклад показує, що в міру зростання числа і складності функцій, які необхідно виконувати, наявність стандартних засобів організації паралельного виконання завдань, роботи з таймером, межзадачного обміну інформацією і т. п. можуть істотно підвищити продуктивність програмістів та зменшити кількість помилок. Саме тут можуть проявити свої позитивні сторони ядра і операційні системи реального часу, як раз такі кошти і що пропонують.
У загальному випадку рішення про застосування будь-якого комерційного ПЗ реального часу залежить від безлічі факторів, у тому числі і від таких, як час, відпущений на розробку, наявність і кваліфікація фахівців, обсяги фінансування проекту і т. п.
Висновок
Хоча, як ми побачили, ОС РВ надають багато корисних і зручних засобів для написання програм, основний тягар відповідальності лежить на плечах рядового трудівника-програміста. Адже варто йому перемістити змінну з категорії локальних в категорію глобальних і забути належним чином оформити критичні секції, як стануть падати космічні кораблі, вибухати нафтопереробні заводи, виділяти радіоактивність атомні станції.
Список використаної літератури
1. Алан Джок «ОС реального часу».
2. http://www.tepcom.ru/produkts/real/Report_Notations_A. asp.
3. http://www.asutp.ru/?p=600591.
4. Зауваження про вибір операційних систем при побудові систем реального часу (А. Жданов, А. лати., ЗАТ "РТСофт", PCWeek, 1 / 2001).
{
for (;;) {
task0 ();
task1 ();
task2 ();
/ * І т. д. * /
}
}
Кожна «завдання», що представляє собою окрему підпрограму, виконується циклічно. При цьому треба дотримуватися наступних правил:
1. Підпрограми не повинні містити циклів очікування в стилі
while (TRUE) {
if (switch_up ()) {
lamp_off ();
break;
}
}
2. Підпрограми повинні виконувати свою роботу як можна швидше, щоб дати можливість працювати наступного підпрограмі.
3. При необхідності підпрограма може зберігати своє оточення і поточні результати, щоб у наступному циклі поновити роботу з того ж місця. Можна відзначити наступні переваги циклічного алгоритму.
1. Простота використання та прозорість для розуміння.
2. Якщо виключити з розгляду переривання, система повністю детермінована. Завдання завжди викликаються в одній і тій же послідовності, що дозволяє досить просто зробити аналіз "найгіршого випадку» і обчислити максимальну затримку.
3. Мінімальні розміри коду і даних. Крім того, на відміну від алгоритмів з витісненням, для всіх задач необхідний тільки один стек.
4. Відсутні помилки, зумовлені «гонками».
До недоліків циклічного алгоритму можна віднести відсутність пріоритетності і черг. До того ж завдання викликаються незалежно від того, чи повинні вони в даний момент чтолибо робити чи ні, а на прикладного програміста лягає максимальна відповідальність за працездатність системи.
Перейдемо тепер до другого широко використовуваному алгоритму планування. Мова піде про режим поділу часу. Існують різні реалізації в рамках цього алгоритму, і деякі західні фахівці навіть розрізняють такі загалом ідентичні для нас поняття, як timeslicing і time-sharing. Як правило, алгоритм реалізується наступним чином: кожного завдання відводиться певна кількість квантів часу (зазвичай кратне 1 мс), протягом яких завдання може монопольно займати процесорний час. Після того як заданий інтервал часу минає, управління передається наступній готової до виконання задачі, що має найвищий пріоритет. Та, у свою чергу, виконується протягом відведеного для неї проміжку часу, після чого все повторюється в стилі round robin. Легко помітити, що такий алгоритм роботи може призвести до певних проблем. Уявімо, що в системі працюють 7 завдань, 3 з яких мають високий пріоритет, а 4 - низький. Низькопріоритетні завдання можуть ніколи не отримати управління, оскільки три високопріоритетні завдання будуть ділити все процесорний час між собою. Єдину можливість для низькопріоритетних завдань отримати управління надає ситуація, коли всі високопріоритетні завдання знаходяться у блокованому стані.
Для вирішення цієї проблеми застосовується прийом, що одержав назву рівнодоступність (fairness). При цьому реалізується принцип адаптивної пріоритетності, коли пріоритет завдання, що виконується занадто довго, поступово зменшується, дозволяючи менш пріоритетним завданням отримати свою частку процесорного часу. Рівнодоступність застосовується головним чином в багатокористувацьких системах і рідко застосовується в системах реального часу.
Кооперативна багатозадачність - це ще один алгоритм перемикання завдань, з яким широкі маси комп'ютерної громадськості знайомі по операційній системі Windows 3.х. Завдання, що отримала управління, виконується до тих пір, поки вона сама за своєю ініціативою не передасть управління іншої задачі. По суті це продовження ідеології round robin, і немає потреби пояснювати, чому алгоритм кооперативної багатозадачності в чистому вигляді мало застосовується в системах реального часу.
Пріоритетна багатозадачність з витісненням - це, мабуть, найбільш часто використовується в ОС РВ принцип планування. Основна ідея полягає в тому, що високопріоритетних завдання, як тільки для неї з'являється робота, негайно перериває (витісняє) низькопріоритетних. Іншими словами, якщо яка-небудь задача переходить в стан готовності, вона негайно отримує управління, якщо поточна активна задача має більш низький пріоритет. Таке «витіснення» відбувається, наприклад, коли високопріоритетних завдання отримала очікуване повідомлення, звільнився запитаний нею ресурс, відбулося пов'язане з нею зовнішня подія, вичерпався заданий інтервал часу і т. п.
Закінчуючи розгляд основних принципів планування завдань, необхідно відзначити, що тема ця далеко не вичерпана. Діапазон систем реального часу досить широкий, починаючи від повністю статичних систем, де всі завдання і їх пріоритети заздалегідь визначені, до динамічних систем, де набір виконуваних завдань, їх пріоритети і навіть алгоритми планування можуть змінюватися в процесі функціонування. Існують, наприклад, системи, де кожна окрема задача може брати участь в будь-якому з трьох алгоритмів планування або їх комбінації (витіснення, поділ часу, кооперативность).
У загальному випадку алгоритми планування повинні відповідати критеріям оптимальності функціонування системи. Однак, якщо для систем «жорсткого» реального часу такий критерій очевидний: «ЗАВЖДИ і ВСЕ робити вчасно», то для систем «м'якого» реального часу це може бути, наприклад, мінімальна «максимальне запізнювання» або середньозважена своєчасність завершення операцій. У залежності від критеріїв оптимальності можуть застосовуватися алгоритми планування завдань, відмінні від розглянутих. Наприклад, може виявитися, що планувальник повинен аналізувати момент видачі критичних за часом керуючих впливів і запускати на виконання те завдання, яке відповідає за найближчі з них (алгоритм earliest deadline first, EDF).
Необхідно відзначити, що в одній обчислювальній системі можуть одночасно співіснувати завдання і «жорсткого», і «м'якого» реального часу, і що тільки одна з цих завдань, що володіє найвищим пріоритетом, може бути по-справжньому детермінованою.
Не варто особливо захоплюватися пріоритетами. Якщо система нормально працює, коли всі завдання мають однаковий пріоритет, то й слава Богу. Якщо ні, то можна привласнити високий пріоритет «критичної» завданню, і низький пріоритет всім іншим. Якщо у вас більше однієї «критичної» завдання, при недостатньому швидкодії системи має сенс розглянути багатопроцесорну конфігурацію або, відмовившись від ПО РВ, перейти до простого циклічного алгоритму.
Як правило, розробники намагаються звести свою систему реального часу до найбільш простим конфігурацій, характерним для систем «жорсткого» реального часу, іноді навіть на шкоду ефективності використання обчислювальних ресурсів. Причина зрозуміла: складні динамічні системи дуже важко аналізувати і налагоджувати, тому краще заплатити за більш потужний процесор, ніж мати в майбутньому проблеми через непередбачуване поведінки системи. У зв'язку з цим більшість існуючих систем реального часу являють собою статичні системи з фіксованими пріоритетами. Часто в системі реалізується кілька «режимів» роботи, кожен з яких має свій набір виконуваних завдань із заздалегідь заданими пріоритетами. Значна частина особливо відповідальних систем, як і раніше реалізується без застосування комерційних ОС РВ взагалі.
3.4. Синхронізація завдань
Хоча кожна завдання в системі, як правило, виконує яку-небудь окрему функцію, часто виникає необхідність в узгодженості (синхронізації) дій, що виконуються різними завданнями. Така синхронізація необхідна, в основному, в наступних випадках.
1. Функції, що виконуються різними завданнями, пов'язані один з одним. Наприклад, якщо одне завдання готує вихідні дані для іншого, то остання не виконується до тих пір, поки не отримає від першого завдання відповідного повідомлення. Одна з варіацій в цьому випадку - це коли завдання за певних умов породжує одну або декілька нових завдань.
2. Необхідно впорядкувати доступ декількох завдань до ресурсу.
3. Необхідна синхронізація завдання із зовнішніми подіями. Як правило, для цього використовується механізм переривань, з яким.
4. Необхідна синхронізація завдання за часом. Діапазон різних варіантів в цьому випадку досить широкий, від прив'язки моменту видачі будь-якого впливу до точного астрономічному часу до простої затримки виконання завдання на певний інтервал часу. Для вирішення цих питань у кінцевому рахунку використовуються спеціальні апаратні засоби, звані таймером.
Давайте розглянемо всі чотири випадки більш докладно.
3.4.1. Пов'язані завдання
Взаємне узгодження завдань за допомогою повідомлень є одним з найважливіших принципів операційних систем реального часу. Способи реалізації межзадачного обміну відрізняються великою різноманітністю, що не в останню чергу призводить до великої кількості термінів у цій галузі. Можна зустріти такі поняття, як повідомлення (message), поштовий ящик (mail box), сигнал (signal), подія (event), проксі (proxy) і т. п. Якщо, читаючи опис якої-небудь ОС РВ, ви зустрінете вже знайому назву, не поспішайте робити висновки. Навіть один і той же термін може для різних ОС РВ позначати різні речі. Щоб не заплутатися, ми будемо надалі називати повідомленнями будь-який механізм явною передачі інформації від однієї задачі до іншої (такі об'єкти, як семафори, можна віднести до механізму неявній передачі повідомлень).
Обсяг інформації, переданої в повідомленнях, може змінюватися від 1 біта до всієї вільної ємності пам'яті вашої системи. У багатьох ОС РВ компоненти операційної системи, так само як і користувальницькі завдання, які спроможні приймати і передавати повідомлення. Повідомлення можуть бути асинхронними і синхронними. У першому випадку доставка повідомлень завданню проводиться після того, як вона в плановому порядку отримає управління, а в другому випадку циркуляція повідомлень безпосередньо впливає на планування завдань. Наприклад, завдання, що послала яке-небудь повідомлення, негайно блокується, якщо для продовження роботи їй необхідно дочекатися відповіді, або якщо низькопріоритетних завдання шле найпріорітетніше завданню повідомлення, якого остання очікує, то високопріоритетних завдання, якщо, звичайно, використовується пріоритетна багатозадачність з витісненням, негайно отримає управління.
Іноді повідомлення передаються через відведений для цього буфер певного розміру («поштова скринька»). При цьому, як правило, нове повідомлення затирає старе, навіть якщо останнє не було опрацьовано.
Однак найбільш часто використовується принцип, коли кожна задача має свою чергу повідомлень, в кінець якої ставиться всяке знову отримане повідомлення. Стандартний принцип обробки черги повідомлень за принципом «першим увійшов, першим вийшов» (FIFO) не завжди оптимально відповідає поставленому завданню. У деяких ОС РВ передбачається така можливість, коли повідомлення від найпріорітетніше завдання обробляється в першу чергу (в цьому випадку говорять, що повідомлення успадковує пріоритет послала його завдання).
Іноді корисним виявляється безпосереднє управління пріоритетом повідомлень. Уявімо, що завдання послала сервера (драйвера) принтера кілька повідомлень, що містять дані для друку. Якщо тепер завдання хоче скасувати всю друк, їй треба послати відповідне повідомлення з більш високим пріоритетом, щоб воно стало в чергу попереду усіх набраних раніше завдань на друк. Повідомлення може містити як самі дані, призначені для передачі, так і покажчик на такі дані. В останньому випадку обмін може здійснюватися за допомогою поділюваних областей пам'яті, поділюваних файлів і т. п.
3.4.2. Загальні ресурси
Важко переоцінити важливість правильної організації взаємодії різних завдань при доступі до загальних ресурсів. Доброю аналогією може служити обід в багатодітній селянській родині минулого століття. Їдоках (завданням) не дозволялося одночасно лізти ложками в загальну миску (ресурс). Порушники порядку могли отримати від батька сімейства (супервізора) ложкою по лобі.
Ресурс - це загальний термін, що описує фізичний пристрій або область пам'яті, які можуть одночасно використовуватися тільки одним завданням. Процесорний час теж являє собою своєрідний конкурентно використовуваний ресурс обчислювальної системи. Прикладом фізичних пристроїв можуть служити клавіатура, дисплей, дисковий накопичувач, принтер і т. п. Уявімо, наприклад, що кілька завдань намагаються одночасно виводити дані на принтер. На роздруківці в результаті нічого, крім дивною мішанини символів, ми не побачимо. В якості іншого прикладу розглянемо ситуацію, коли в бортовому комп'ютері мирно літака МІГ-29 серед інших працюють два завдання. Одна з них, взаємодіючи з радіолокаційною системою, видає видалення і напрямок до мети, а інше завдання використовує ці дані для пуску ракет класу «повітря-повітря». Не виключено, що перше завдання, записавши в глобальну структуру даних видалення до мети, буде перервана другим завданням, не встигнувши записати туди напрямок до мети. У результаті друга задача вважає з цієї структури помилкові дані, що може призвести до невдалого пуску з усіма наслідками, що випливають звідси неприємними наслідками. Перервіть перше завдання трохи пізніше, і все було б нормально. Згадані тут проблеми обумовлені времязавісімимі помилками (time dependent error), або «гонками» і характерні для багатозадачних ОС, що застосовують алгоритми планування з витісненням (до речі, системи з розділенням часу також відносяться до категорії «витісняють»).
Наведений приклад показує, що помилки, зумовлені «гонками»,
а) характерні для роботи з будь-якими ресурсами, доступ до яких мають кілька завдань, і б) відбуваються тільки в результаті збігу певних умов, а тому з працею виявляються на етапі налагодження. Ось можливі шляхи вирішення проблеми.
1. Не використовувати алгоритми планування завдань з витісненням. Це рішення, щоправда, не завжди прийнятно.
2. Використовувати спеціальний сервер ресурсу, тобто завдання, відповідальну за упорядкування доступу до ресурсу. У цьому випадку запит на зміну значення глобальних даних надсилається цього сервера у вигляді повідомлення. Аналогічний підхід застосуємо і для фізичних пристроїв. Так, наприклад, завдання може послати дані на друк у вигляді повідомлення, направленого до сервера принтера.
3. Заборонити переривання на час доступу до даних, що розділяються. Кардинальне рішення, яке, втім, не вітається в системах реального часу.
4. Використовувати для упорядкування доступу до глобальних даними семафори. Найбільш часто застосовується рішення, яке, втім, може привести в деяких випадках до «інверсії пріоритетів».
Останній пункт стоїть прокоментувати докладніше, оскільки поняття «семафор» зустрічається вперше.
Семафор - це якраз той засіб, який часто використовується для синхронізації доступу до ресурсів. У найпростішому випадку семафор представляє собою байтове змінну, приймаючу значення 0 або 1. Завдання, перед тим як використовувати ресурс, захоплює семафор, після чого інші завдання, які бажають використовувати той самий ресурс, повинні чекати, поки семафор (ресурс) звільниться. Існують також так звані рахункові семафори, де семафор представляє собою лічильник. Нехай до системи підключено три принтера. Семафор, що відповідає за доступ до функцій друку, ініціалізується із значенням 3, а потім кожного разу, коли яка-небудь задача запитує семафор для здійснення друку, його значення зменшується на 1. Після друку завдання звільняє семафор, в результаті чого значення останнього збільшується на 1. Якщо поточне значення семафора дорівнює 0, то ресурс вважається недоступним, і завдання, що запитують друк, повинні чекати, поки не звільниться хоча б один принтер. Таким чином може здійснюватися синхронізація доступу безлічі завдань до групи з 3 принтерів. Так як за своєю суттю семафор також являє собою глобальну змінну, всі неприємності, які згадувалися раніше в зв'язку з літаком МІГ-29, по ідеї, повинні чекати нас і тут. Однак, так як робота з семафорами відбувається на рівні системних викликів, програміст може бути впевнений, що розробники операційної системи про все заздалегідь подбали.
Перейнявшись свідомістю того, наскільки небезпечно змінювати глобальні змінні в умовах, коли всі навколо так і норовлять одне одного витіснити, ділянки коду програм, де відбувається звернення до ресурсів, називаються критичними секціями.
Так як процеси звичайно не мають доступу до даних один одного, а ресурси фізичних пристроїв, як правило, управляються спеціальними завданнями-серверами (драйверами), найбільш типова ситуація, коли «гонки» за доступ до глобальних змінних влаштовують різні потоки, що виконуються в рамках одного програмного модуля. Для того щоб гарантувати, що критична секція коду виконується в кожний момент часу лише одним потоком, використовують механізм взаємовиключення доступу, або просто мутексов (Mutual Exclusion Locks, Mutex). Практично мутекс представляє собою різновид семафора, який сигналізує іншим потокам, що критична секція коду ким-то вже виконується.
Критична секція, яка використовує мутекс, повинна мати певні суффіксную і префіксной частини. Наприклад:
int global_counter;
void main (void)
{
mutex_t mutex;
(
/ * І все це лише для того, щоб збільшити глобальну змінну на одиницю .* /
mutex_init (& mutex, USYNC, NULL);
mutex_lock (& mutex);
global_counter + +;
mutex_unlock (& mutex);
}
Якщо мутекс захоплений, то потік, який намагається увійти у критичну секцію, блокується. Після того як мутекс звільняється, один з стоять у черзі потоків (якщо такі накопичилися) розблокується і отримує можливість доступу до глобального ресурсу.
Думаю, на цьому розгляд засобів синхронізації доступу до загальних ресурсів можна закінчити, хоча, звичайно, безліч тим залишилося за дужками. Наприклад, в WIN32 використовується, в числі іншого, спеціальний різновид мутексов під назвою Critical Section Object. Необхідно також пам'ятати, що, крім ОС, що мають WIN32 або POSIX API, існує велика кількість ні з чим не сумісних ОС, тому наявність коштів синхронізації та особливості їх реалізації повинні розглядатися окремо для кожної конкретної ОС РВ.
А ось можливі неприємності у боротьбі за ресурси.
Смертельний захоплення (Deadlock). У народі побічні прояви цієї ситуації називаються більш прозаїчно - «зациклення» або «зависання». А причина цього може бути досить проста - «завдання не поділили ресурси». Нехай, наприклад, Завдання А захопила ресурс клавіатури і чекає, коли звільниться ресурс дисплея, а в цей час Задача також хоче поспілкуватися з користувачем і, встигнувши захопити ресурс дисплея, чекає тепер, коли звільниться клавіатура. Так і будуть завдання чекати один одного до другого потопу, а користувач буде в цей час дивитися на порожній екран і лаяти останніми словами яйцеголових програмістів, які не змогли зробити нормально працюючу систему. У таких випадках рекомендується дотримуватися тактики «або все, або нічого». Іншими словами, якщо завдання не змогла отримати всі необхідні для подальшої роботи ресурси, вона повинна звільнити все, що вже захоплено, і, як кажуть, «зайти через півгодини». Іншим рішенням, яке вже згадувалося, є використання серверів ресурсів.
Інверсія пріоритетів (Priority inversion). Як вже зазначалося, алгоритми планування завдань (управління доступом до процесорного часу) повинні знаходитися у відповідності з методами управління доступом до інших ресурсів, а всі разом - відповідати критеріям оптимального функціонування системи. Ефект інверсії пріоритетів є наслідком порушення гармонії в цій області. Ситуація тут схожа на «смертельний захоплення», проте сюжет закручений ще більше лихо. Уявімо, що у нас є високопріоритетних Завдання А, среднепріорітетная Завдання В і низькопріоритетних Завдання С. Нехай в початковий момент часу Завдання А і В блоковані в очікуванні якої-небудь зовнішньої події. Припустимо, що отримала в результаті цього управління Завдання З захопила Семафор А, але не встигла вона його віддати, як була перервана Завданням А. У свою чергу, Завдання А при спробі захопити Семафор А буде блокована, тому що цей семафор вже захоплений Завданням С. Якщо до цього часу Завдання В знаходиться в стані готовності, то управління після цього отримає саме вона, як має більш високий, ніж у Завдання С, пріоритет. Тепер Завдання В може займати процесорний час, поки їй не набридне, а ми отримуємо ситуацію, коли високопріоритетних Завдання А не може функціонувати через те, що необхідний їй ресурс зайнятий низькопріоритетний Завданням С.
3.4.3. Синхронізація з зовнішніми подіями
Відомо, що застосування апаратних переривань є більш ефективним методом взаємодії із зовнішнім світом, ніж метод опитування. Розробники систем реального часу намагаються використати цей факт в повній мірі. При цьому можна простежити такі тенденції:
1. Прагнення забезпечити максимально швидку і детерміновану реакцію системи на зовнішню подію.
2. Намагання домогтися мінімально можливих періодів часу, коли в системі заборонені переривання.
3. Підпрограми обробки переривань виконують мінімальний обсяг функцій за максимально короткий час. Це обумовлено декількома причинами. По-перше, не всі ОС РВ забезпечують можливість «витіснення» під час обробки підпрограм переривання. По-друге, пріоритети апаратних переривань не завжди відповідають пріоритетам завдань, з якими вони пов'язані. По-третє, затримки з обробкою переривань можуть призвести до втрати даних.
Як правило, закінчивши елементарно необхідні дії, підпрограма обробки переривань генерує в тій або іншій формі повідомлення для завдання, з якою це переривання пов'язано, і негайно повертає управління. Якщо це повідомлення перевело завдання в розряд готових до виконання, планувальник в залежності від використовуваного алгоритму і пріоритету завдання приймає рішення про те, чи необхідно ні негайно передати управління отримала повідомлення завданню. Зрозуміло, це всього лише один з можливих сценаріїв, так як кожна ОС РВ має свої особливості при обробці переривань. Крім того, свою специфіку може накладати використовувана апаратна платформа.
3.4.4. Синхронізація за часом
Зовсім не так давно (років 20 тому) апаратні засоби, що відповідають в обчислювальних системах за службу часу, були абсолютно не розвинені. У ті вікопомні часи вважалося достатнім, якщо в системі генерувалося переривання з частотою мережі змінного струму. Ті ж, хто не знав, що частота мережі в США 60 Гц, а не 50, як у нас, постійно дивувалися тому, що системний час у RSX-11M ніколи не буває правильним. Програмісти для отримання затримок за часом часто використовували програмні цикли очікування і, зрозуміло, користувачі таких програм отримували масу сюрпризів при спробі їх перенесення на наступне покоління комп'ютерів з більш високими тактовими частотами. Слава Богу (або науково-технічному прогресу), зараз будь-який мало-мальськи пристойний комп'ютер має годинник / календар з батарейною підтримкою і багатофункціональний таймер (а то й кілька) з роздільною здатністю до одиниць мікросекунд.
Як правило, в ОС РВ задається еталонний інтервал (квант) часу, який іноді називають тиком (Tick) і який використовується в якості базової одиниці виміру часу. Розмірність цієї одиниці для різних ОС РВ може бути різною, як, втім, різними можуть бути набір функцій і механізми взаємодії з таймером. Функції по роботі з таймером використовують для призупинення виконання завдання на якийсь час, завдання для запуску в певний час, для відносної синхронізації декількох завдань за часом і т. п. Якщо в програмі для ОС РВ ви побачите операнд delay (50), то , швидше за все, це означає, що в цьому місці завдання має перерватися (блокуватися), а через 50 мс відновити своє виконання, а точніше, перейти в стан готовності. Весь цей час процесор не простоює, а вирішує інші завдання, якщо такі є. Безліч завдань одночасно можуть запросити сервіс таймера, тому якщо для кожного такого запиту використовується елемент в таблиці тимчасових інтервалів, то накладні витрати системи з обробки переривань від апаратного таймера ростуть пропорційно розмірності цієї таблиці і можуть стати неприпустимими. Для вирішення цієї проблеми можна замість таблиці використовувати зв'язний список та алгоритм так званого диференціального таймера, коли під час кожного тика зменшується тільки один лічильник інтервалу часу.
Для точної синхронізації таймера обчислювальної системи з астрономічним часом можуть застосовуватися спеціальний годинник з підстроюванням за радіосигналами точного часу або навігаційні приймачі GPS, які дозволяють скористатися атомним годинником на борту орбітальних космічних апаратів, запущених за програмою Navstar.
4. Тестування
Перш ніж встановлювати вашу систему реального часу на не менш реальному об'єкті, рекомендується перевірити її працездатність за допомогою інтенсивних тестів. Це особливо важливо для складних динамічних систем. Під час такого тестування бажано змоделювати найбільш неприємні і «важкі» режими роботи, аварійні ситуації і т. п. При умоглядному аналізі простих систем слід обережно ставитися до рекламної інформації розробників ОС РВ, які з комерційних міркувань показують, як правило, параметри для «кращого випадку ». Наприклад, якщо мова йде про максимальне часу обробки переривання, необхідно в першу чергу зрозуміти, а що, власне, мається на увазі під цим часом:
а) час від виникнення запиту на переривання до передачі керування по векторі переривання;
б) або включаючи час збереження контексту поточного завдання та передачі управління підпрограмі обробки переривання;
в) або додатково до цього ще й час до завершення підпрограми обробки переривання і передачі повідомлення пов'язаної з перериванням завданню;
г) або додатково до цього час до моменту, коли це завдання нарешті отримає управління (у припущенні, що вона є найбільш пріоритетною) і почне реальну обробку події.
Безвідносно до того, який варіант розглядається, необхідно пам'ятати, що
1) якщо поряд з розробленими вами програмами використовується програмне забезпечення третіх фірм, ви не застраховані від того, що там не зустрінуться ділянки коду, де переривання заборонені;
2) практично будь-яка ОС РВ має у своїх надрах ділянки такого коду. Нам залишається тільки сподіватися, що розробники ОС намагалися робити їх якомога менше;
3) всі ядро ОС РВ або його ділянки можуть бути «не витісняє»;
4) інтелектуальні контролери введення / виводу типу SCSI можуть ініціювати в системі різні службові операції, які здатні позначитися на її характеристиках;
5) багато чого залежить від вживаної системи кешування. Тому, якщо ваше подія відбулася в «невідповідний» час, реальні показники швидкодії можуть сильно відрізнятися від рекламованих.
5. Чи можна обійтися без ОС РВ?
Як будь-яку обчислювальну систему можна створити тільки з елементів 2И! НЕ, так і все, що може робити ОС РВ, реалізоване і без неї. Тим не менш, давайте все-таки спробуємо розібратися, коли ОС РВ реально потрібна, а коли ні. Припустимо, нам треба не рідше 10 разів на секунду опитати три перемикачі і залежно від їх положення включити або виключити відповідний насос.
Програма може виглядати наступним чином:
void main (void)
{
int i;
for (;;) {
for (i = 0; i <3; i + +) {
if (switch_was_changed (i)) change_Pump (i);
}
}
}
Зауважте, що ніяких перевірок з дня немає, тому що навіть самі повільні процесори можуть сканувати перемикачі частіше 10 разів на секунду. Програма адекватна поставленій задачі. Якщо потрібно опитувати перемикачі рівно 10 разів на секунду, програма може бути змінена:
for (;;) {
if (100msec_passed) {
for (i = 0; i <3; i + +) {
if (switch_was_changed (i) change_Pump (i);
}
100msec_passed = 0;
}
}
Глобальна змінна 100msec_passed встановлюється в «1» кожні 100 мс за допомогою підпрограми обробки переривань від таймера. Тепер припустимо, що нам додатково потрібно кожні 200 мс вимірювати тиск і відкривати вентиль, якщо тиск більше 20 атм. Якщо при відкритому вентилі тиск падає нижче 15 атм, вентиль необхідно закрити. Для виконання цього завдання в тіло циклу може бути доданий наступний фрагмент:
if (200msec_passed) {
switch (valve_status) {
case CLOSED:
if (divssure_value ()> 20) {
open_valve (); valve_status = OPEN;
}
case OPEN:
if (divssure_value () <15) {
close_valve (); valve_status = CLOSED;
}
}
200msec_passed = 0;
}
Глобальна змінна 200msec_passed встановлюється в 1 кожні 200 мс. Оскільки тіло циклу for (;;) стало великим, зручно винести функції в окремі підпрограми і переписати основну програму наступним чином: for (;;) {process_pump_switches (); process_divssure_regulation ();} У міру того як додаються нові «завдання», їх можна оформляти окремими підпрограмами і включати відповідні виклики в тіло головної програми. Однак у міру додавання нових функцій час виконання основного циклу збільшується, в результаті чого може наступити момент, коли вимога про сканування перемикачів 10 разів на секунду перестане виконуватися. Давайте ще трохи ускладнити завдання. Нехай система має відображати тренди на основі пакетів даних, одержуваних через швидкодіючий послідовний порт. У цьому випадку основна програма може виглядати як
for (;;) {
process_pump_switches ();
process_divssure_regulation ();
show_trend ();
}
Якщо функція show_trend викликається з запізненням, то пакет даних може бути втрачений. Рішенням цієї проблеми може бути винос комунікаційних функцій з show_trend і організація черги, куди при обробці переривань послідовного порту поміщається черговий заповнений пакет для подальшої обробки за допомогою show_trend.
Наведений тут приклад ілюструє циклічний (round robin) механізм виконання завдань, цілком відповідний для багатьох застосувань. Однак цей же приклад показує, що в міру зростання числа і складності функцій, які необхідно виконувати, наявність стандартних засобів організації паралельного виконання завдань, роботи з таймером, межзадачного обміну інформацією і т. п. можуть істотно підвищити продуктивність програмістів та зменшити кількість помилок. Саме тут можуть проявити свої позитивні сторони ядра і операційні системи реального часу, як раз такі кошти і що пропонують.
У загальному випадку рішення про застосування будь-якого комерційного ПЗ реального часу залежить від безлічі факторів, у тому числі і від таких, як час, відпущений на розробку, наявність і кваліфікація фахівців, обсяги фінансування проекту і т. п.
Висновок
Хоча, як ми побачили, ОС РВ надають багато корисних і зручних засобів для написання програм, основний тягар відповідальності лежить на плечах рядового трудівника-програміста. Адже варто йому перемістити змінну з категорії локальних в категорію глобальних і забути належним чином оформити критичні секції, як стануть падати космічні кораблі, вибухати нафтопереробні заводи, виділяти радіоактивність атомні станції.
Список використаної літератури
1. Алан Джок «ОС реального часу».
2. http://www.tepcom.ru/produkts/real/Report_Notations_A. asp.
3. http://www.asutp.ru/?p=600591.
4. Зауваження про вибір операційних систем при побудові систем реального часу (А. Жданов, А. лати., ЗАТ "РТСофт", PCWeek, 1 / 2001).