3.2. Організація моделі системи
Модель цієї системи може бути організована відповідно до наступних двох принципів:
будується і безперервно підтримується хронологічно упорядкований список подій;
існує програма обробки події для кожного типу події (ця програма викликається, як тільки подія цього типа виявиться черговою в списку подій).
Таким чином, для кожного ресурсу R в цій системі повинні існувати три програми:
R_ ЗАПИТ
R_ ПРИЗНАЧЕННЯ
R_ЗВІЛЬНЕННЯ.
Ці програми одержують ім'я завдання J як аргумент і можуть виконувати наступні завдання:
Завдання R_ЗАПИТ(J): якщо ресурс R можна негайно призначити завданню J
тоді створити подію «призначити ресурс R завданню J» і змінити стан R
інакше поставити завдання J в чергу до відповідного ресурсу R.
Завдання R _ ПРИЗНАЧЕННЯ (J): планувати наступну подію для завдання J (яке не обов'язково буде подією «звільнення R»).
Завдання R_ЗВІЛЬНЕННЯ (J):
модифікувати стан ресурсу R;
планувати наступну подію для завдання J;
якщо ресурс R можна негайно призначити завданню К, що в черзі до ресурсу R
то планувати подію «призначити ресурс R завданню К» і виключити завдання з черги до ресурсу R;
інакше нічого не робити.
Відмітимо, що всі програми обробки подій здатні змінювати список подій, створюючи нові події і плануючи їх на деякий майбутній час моделі.
Легко бачити, що програма R.ПРИЗНАЧЕННЯ (J) може бути об'єднана з програмою R.ЗАПИТ(J), як показано на рис. 3.2, б, за умови, що основні операції визначених вище програм модифіковані, наприклад, таким чином:
R-ЗАПИТ/ПРИЗН (J): якщо ресурс R можна негайно призначити завданню J
то змінити стан ресурсу R і планувати наступну подію для завдання J;
інакше поставити запит від завдання J в чергу до ресурсу R;
R_ЗВІЛЬНЕННЯ (J):
змінити стан ресурсу R;
планувати наступну подію для завдання J;
якщо черга до ресурсу R не порожня
то планувати подію «запит/призначення ресурсу R завданню К» і прибрати завдання з черги до ресурсу R;
інакше нічого не робити.
Рис. 3.2. Типи подій в завданнях і типи дій, що відносяться до ресурсу R
Слід відмітити, що в цій схемі постановка в чергу до ресурсу R проводиться програмою R _ЗАПИТ/ПРИЗН (J), а виключення − програмою R-ЗВІЛЬНЕННЯ (J).
Стратегії планування і призначення ресурсу R здійснюються програмою R_.ЗВІЛЬНЕННЯ (J).
Коли ця програма вибирає завдання для негайного призначення ресурсу R, потрібна гарантія від повторного приміщення в чергу цього ж завдання програмою R. ЗВІЛЬНЕННЯ. Таку гарантію можна одержати, наприклад, помітивши особливим чином ім'я завдання (К), яке передається програмі R_3AПP/HA3H.
Розглянемо як визначають наступну подію для завдання J описані вище дві програми обробки подій.
Щоб відповісти на це питання, ми повинні детальніше визначити шлях, прохідний завданням через нашу систему. Для цієї мети необхідно додати до типів подій, зображених на рис. 3.2, б, ще два: події надходження і відхід.
Процеси надходження і відходу відрізняються від процесів запит/призначення і звільнення в основному тим, що не існує прямого зв'язку між появами і відходами.
Якщо ми розглянемо всю систему як єдиний ресурс, то побачимо, що цей ресурс негайно призначається будь-якому завданню, що поступає, незалежно від відходу завдань (відмітимо, що це не так для чисто діалогової системи).
Таким чином програма НАДХОДЖЕННЯ повинна планувати появу наступного завдання, а програма ВІДХІД виявляється набагато простішою за програму ЗВІЛЬНЕННЯ.
Два важливі зауваження.
По-перше, стійкість моделі, що визначається як її здатність точно моделювати систему з конфігураціями або робочими навантаженнями, не перевіреними експериментально і що навіть не передбачалися при її створенні, звичайно зростає із зростанням детальності.
По-друге, необхідна точність залежить від цілей роботи, наприклад від того, чи цікавиться оцінювач абсолютними або відносними значеннями індексів продуктивності.
Завдання НАДХОДЖЕННЯ (J):
готує характеристику завдання J;
планує наступну подію для J;
планує прибуття наступного завдання, скажемо К;
ВІДХІД(J): знищує характеристику J.
Тепер можна побудувати те, що назвемо картою подій нашої системи. Ця карта, показана на рис. 3.3, відображає шлях завдання через систему, яку ми хочемо моделювати. Деякі припущення щодо поведінки системи були згадані вище, але легко можуть бути одержані з карти.
Рис. 3.3. Карта подій ПРОП-системи
(написи біля стрілок описують дії; написи у фігурних дужках містять умови, при яких виконується дана дія)
На карті подій, зображеній на рис. 3.3, є 20 прямокутників, які відповідають подіям. Чотирнадцять прямокутників (по два на кожний з шести ресурсів плюс «надходження» і «відхід») відповідають різним типам подій.
Модель формулюється на 14 програмах, що оброблюють ці типи подій.
Програми можна організувати згідно блок-схемі рис. 3.2.
Програма ініціалізації просто будує структури даних моделі і приводить їх у початковий стан.
Програма управління моделлю (ПУМ) виконує два основні завдання, а саме:
вибрати наступну подію і викликати відповідну програму обробки події;
перевести годинник моделі, який вимірює час моделі.
Обидва завдання можуть бути виконані шляхом перевірки верхнього запису із списку подій.
Кожен запис в списку містить тип події, який використовується для виклику відповідної програми обробки події (наприклад, ЦП-.ЗВІЛЬНЕННЯ), ім'я завдання, яке потрібно передати як аргумент програмі обробки події, а також час події, яка повинна бути завантажена в годинник моделі програмою управління моделлю.
Момент виникнення події визначається програмою обробки події, яка його генерує. Наприклад, програма ЦП_ЗАПИТ/ /ПРИЗН (J) в деяких випадках обчислює момент часу моделі, коли буде припинене виконання завдання J із-за запиту на системний диск або робочий диск (закінчення кроку завдання викликає запит системного диска). Це обчислення засноване на поточному значенні часу моделі і на тривалості наступного обчисленого інтервалу для завдання J, який можна одержати з опису завдання.
McDougall M.H. 1970 Computer system simulation: An introduction. Comp. Surveys 2, 3 (Sept), 191-209
http://dl.acm.org/citation.cfm?id=802498