з найбільш раннім терміном з вільним часом простою
Якщо граничний час завдань відомо до того, як завдання стають готовими до виконання, необхідно удосконалити цю систему планування за рахунок застосування системи, іменованої плануванням з найбільш раннім граничним терміном початку з вільним часом простою. Вона працює таким чином.
Планувальник завжди запускає підходяще завдання з найбільш раннім граничним терміном початку, яке виконується до повного завершення. Підходяще завдання може виявитися не готовим, і це може призвести до того, що, незважаючи на наявність готових до виконання завдань, процесор простоює. Наша система утримується від виконання завдання А, незважаючи на те, що це єдине готове до виконання завдання. В результаті, хоча процесор і не використовується з максимальною ефективністю, всі вимоги до граничних строків початку виконання завдань при такому плануванні задовольняються.
Малюнок 1.17? Планування з використанням стратегії FCFS.
Для порівняння на малюнку 1.17 наведено результат використання стратегії FCFS «першим надійшов - першим обслужений». Як видно, в цьому випадку відхиленим виявляється завдання - В.
Завдання №2
Для заданої групи обчислювальних процесів організувати доступ до критичний секції з використанням передачі повідомлень .
Пояснити переваги і недоліки кожного з методів взаємного виключення або організації доступу до ресурсів, що розділяються. Привести приклади використання в Windows 2000/XP.
Передача повідомлень.
Передача повідомлень
У раті чогось іншого виступає передача повідомлень. Цей метод процесами взаємодії використовує два примітиву: send і receive, які скоріше є системними викликами, ніж структурними компонентами мови (що відрізняє їх від моніторів і робить схожим на семафори). Тому їх легко можна помістити в бібліотечні процедури, наприклад sendtcfcsttration.iross-sge): r «: eive (scarce. Snessas?»:
Перший запит посилає повідомлення заданому адресата, а другий отримує повідомлення від вказаного джерела (або від будь-якого джерела, якщо его не має значення). Якщо повідомлення немає, другий запит блокується до надходження повідомлення або негайно повертає код помилки.
Розробка систем передачі повідомлень
З системами передачі повідомлень пов'язана велика кількість складних проблем і конструктивних питань, яких не виникає у разі семафорів і моніторів. Особливо багато складнощів з'являється у випадку взаємодії процесів, що відбуваються на різних комп'ютерах, з'єднаних мережею. Так, повідомлення може загубитися і мережі. Щоб уникнути втрати повідомлень, відправник і одержувач домовляються, що при отриманні повідомлення одержувач посилає назад прийняти повідомлення. Якщо відправник не одержує підтвердження через деякий час, він відсилає повідомлення ще раз.
Тепер уявімо, що повідомлення отримане, але підтвердження до відправника не дійшло. Відправник пошле повідомлення ще раз, і до одержувача воно дійде двічі. Вкрай важливо, чюби одержувач міг відрізнити копиця попереднього повідомлення від нового. Зазвичай проблема вирішується за допомогою приміщення порядкового номера повідомлення в тіло самого повідомлення. Якщо до одержувача приходить лист з номером, що збігається з номером попереднього листа, лист класифікується як копія та ігнорується. Рішення проблеми успішного обміну інформації в умовах ненадійною передачі повідомлень становить основу вивчення комп'ютерних мереж.
Для систем обміну повідомленнями також важливе питання назв процесів. Необхідно однозначно визначати процес, зазначений у запиті send або receive. Крім того, постає питання аутентифікації: яким чином клієнт може визначити, що він взаємодіє з справжнім файловим сервером, а не з самозванцем?
Крім цього, існують конструктивні проблеми, істотні при розташуванні відправника і одержувача на одному комп'ютері. Однією з таких проблем є продуктивність. Копіювання повідомлень з одного процессав іншої відбувається набагато повільніше, ніж операція на семафорі або увійти в монітор. Було проведено безліч досліджень з метою збільшення ефективності передачі повідомлень. В (65), наприклад, пропонувалося обмежувати розмір повідомлення до розмірів регістра і передавати повідомлення через регістри. Рішення проблеми виробника і споживача з передачею повідомлень. Тепер розглянемо вирішення проблеми виробника і споживача з передачею повідомлень і без використання розділеної пам'яті. Рішення представлено в лістингу. Ми припускаємо, що всі повідомлення мають однаковий розмір і повідомлення, які надіслані, але ще не отримані, а...
