Теорія операційної системи

:: Меню ::

Головна
Представлення даних в обчислювальних системах
Машинні мови
Завантаження програм
Управління оперативною пам'яттю
Сегментна і сторінкова віртуальна пам'ять
Комп'ютер і зовнішні події
Паралелізм з точки зору програміста
Реалізація багатозадачності на однопроцесорних комп'ютерах  
Зовнішні пристрої
Драйвери зовнішніх пристроїв
Файлові системи
Безпека
Огляд архітектури сучасних ОС

:: Друзі ::

Карта сайту
 

:: Статистика ::

 

 

 

 

 

цена на сборку душевой кабины

Системи, керовані подіями

На початку 70-х років з'явилася нова архітектура багатозадачних систем що досить різко відрізняється від вищеописаної моделі послідовних процесів. Йдеться про так званих системах, керованих подіями (event-driven systems).
На перший погляд, концепція систем, керованих подіями, близько родинна гармонійно взаємодіючим процесам. В усякому разі, одне з ключових понять цієї архітектури, черга подій, ми згадували в числі засобів гармонійної міжпоточної взаємодії. Відмінність між цією архітектурою полягає, швидше, в погляді на те, що є програма.
У моделі гармонійно взаємодіючих потоків процесом виконання програмного комплексу є сукупність взаємодіючих ниток управління. У системі, керованій подіями, програма є сукупністю об'єктів, що обмінюються повідомленнями про події, а також що реагують на повідомлення, що приходять із зовнішніх джерел.
У ідеалі, об'єкти взаємодіють між собою лише через повідомлення. Повідомлення, що приходять, спонукають об'єкт змінити свій достаток і, можливо, породити деяку кількість повідомлень, призначених для інших об'єктів. При такій моделі взаємодії нам неважливо, чи виконуються методи об'єктів як паралельні (або псевдопаралельні) нитки, або ж послідовно викликаються єдиною ниткою, менеджером або диспетчером повідомлень.
Вперше ця архітектура була реалізована в експериментальних настільних комп'ютерах Alto, розроблених в 1973 році в дослідницькому центрі PARC фірми Xerox. Метою експерименту було створення операційної середи, зручної для створення інтерактивних програм з динамічним призначеним для користувача інтерфейсом.
У цих системах вперше була реалізована багатовіконна графіка, коли користувач одночасно бачить на екрані графічне виведення декількох програм і може активізувати будь-яку з них, вказавши на відповідне вікно за допомогою маніпулятора-"миши".
При кожному русі миші, натисненні на її кнопки або клавіші на клавіатурі генерується подія. Події можуть також генеруватися системним таймером або призначеними для користувача програмами. Не можна не згадати "візуальні" події, які породжуються за ситуації, коли користувач
зрушив або закрив одне з вікон і відкрив при цьому частину вікна, що знаходилося внизу. Цьому вікну посилається подія, що говорить про те, що йому потрібно перемальовувати частину себе (мал. 7.10).

Мал. 7.10. Візуальна подія

Кожне повідомлення про подію є структурою даних, яка містить код, що позначає типа події: рух миші, натиснення кнопки і т. д., а також поля, різні для різних типів подій. Для "мишачих" подій — це поточні координати миші і бітова маска, що позначає достаток кнопок (нажата/отпущена). Для клавіатурних подій — це код клавіші, що натискує, зазвичай, ASCII-код символу для алфавітно-цифрових і спеціальні коди для стрілок і інших "розширених" і "функціональних" клавіш — і бітова маска, що позначає достаток різних модифікаторів, таких як SHIFT, CNTRL, ALT і так далі Для візуальних подій — це координати прямокутника, який потрібно перемальовувати, і так далі
Всі повідомлення про події поміщаються в чергу в порядку їх виникнення.
У системі існує поняття обробника подій. Обробник подій Є об'єктом, тобто структуру даних, з якою пов'язано декілька підпрограм — методів. Один з методів викликається під час вступу повідомлення. Зазвичай він також називається обробником подій. Деякі системи пропонують об'єктам-обробникам надавати різні методи для обробки різних подій — наприклад, метод onclick викликатиметься, коли прийде подія, що сигналізує про те що кнопка миші натискувала і відпущена, коли курсор знаходився над областю, займаною об'єктом на екрані.
Розглянемо об'єкт графічного інтерфейсу, наприклад меню. При натисненні на кнопку миші в області цього меню викликається обробник події Він розбирається, який з пунктів меню був вибраний, і посилає відповідне командне повідомлення об'єкту, з яким асоційовано меню Цей об'єкт, у свою чергу, може послати командні повідомлення якимсь іншим об'єктам. Наприклад, якщо була вибрана команда File/open, меню передасть обробникові основного вікна додатка повідомлення FILEOPEN, а той, у свою чергу, може передати команду Open об'єкту, що відповідає за отрісовку і обробкою файлового діалогу.
Таким чином, замість програми, що послідовно виконується, час від часу викликає систему для виконання тієї або іншої функції, ми отримуємо набір обробників, що викликаються системою відповідно до бажань користувача. Кожен окремий обробник є кінцевим автоматом, інколи навіть вироджений, такий, що не має змінної достатку. Код обробника і по реалізації зазвичай схожий на кінцевий
автомат, і полягає m великого оператора switchщо вибирає різні дії залежно від типа повідомлення, що прийшло (приклад 7.8).

Приклад 7.8. Обробник віконних подій в Os/2 Presentation Manager

/* фрагмент прикладу з постачання IBM Visual Age for C++ 3.0.
* Обробник подій меню надається системою
* а обробку командних подій, породжуваних меню
* вимушений брати на себе розробник додатка. */
/****************************************************************
Copyright (С) 1992 IBM Corporation
ВІДМОВА ВІД ГАРАНТІЙ. Наступним кодом є приклад коди створений IBM Corporation. Цей приклад коди не є частиною жодного стандарту або продукту IBM і надається вам з єдиною метою — допомогти в розробці ваших застосувань. Код надається "Як є", без яких-небудь гарантій. IBM не несе відповідальності за які б то не було пошкодження, виниклі в результаті використання вами цієї коди, навіть якщо вона і могла передбачати можливість таких пошкоджень.

/****************************************************************
* Ім'я: Mainwndproc *
Опис: Віконна процедура головного вікна клієнта. *
* Концепції: Обробляє повідомлення, що посилаються головному
вікну клієнта. Ця процедура обробляє основні повідомлення, які повинні обробляти всі клієнтські вікна, і передає все останні [функції] Userwndproc, в якій розробник може обробити будь-які інші
повідомлення. *
API: He використовуються
* Параметри: hwnd — Ідентифікатор вікна, якому адресовано повідомлення
* msg — Тип повідомлення
* mpl — Перший параметр повідомлення
* тр2 — Другий параметр повідомлення.
* Повертане значення: визначається типом повідомлення
*/
****************************************************************
MRESULT EXPENTRY Mainwndproc(HWND hwnd, USHORT msg, MPARAM mpl
MPARAM mp2)
{
switch(msg){
case Wm_create:
return(Initmainwindow(hwnd, mpl, mp2)};
break;
case Wm_paint:
«
Mainpaint(hwnd); break;
case Wm_command:
Maincommand(mpl. mp2); break;
case Wm_initmenu:
Ini tmenu(mpl, mp2); break;
case Hm_query_keys_help:
return (MRESULT) Panel_helpkeys;/* Повернути Id панелі підказки ' break;
/*
* Всі необроблені повідомлення передаються
* призначеній для користувача процедурі вікна.
* Вона відповідає за передачу всіх необроблених
* повідомлень функції Windefwindowproc(); */
default:
return(Userwndproc(hwnd, msg, mpl, mp2)); break;
return (MRESULT) O; /* Всі віконні процедури повинні за умовчанням повертати 0 */
} /* Кінець Mainwndproc() */

/****************************************************************
* Ім'я: Maincommand
* Призначення: Головна процедура вікна, оброблювальна Wm_command *
* Концепції: Процедура викликається, коли повідомлення Wm_command
* вирушає головному вікну. Оператор switch
* перемикається залежно від id меню, яке
* породило повідомлення і робить дії
* відповідні цьому пункту меню. Все id меню
* що не є частиною стандартного набору команд
* передаються призначеній для користувача процедурі обробки
* Wm_command.
* API : Winpostmsg *
* Параметри : mpl — Перший параметр повідомлення
тр2 — Другий параметр повідомлення *
* Повертає: VOID *
\*************+**************************************************^
VOID Maincommand(MPARAM mpl, MPARAM mp2)
switch(Short1frommp(mpl))
I
case Idm_exit:
Winpostmsg( hwndmain, Wm_quit, NULL, NULL break;
case IDM__FILENEW: Filenew(mp2); break;
case Idm_fileopen: Fileopen(mp2); break;
case Idm_filesave: Filesave(mp2); break;
case Idm_filesaveas: Filesaveas(mp2); break;
case Idm_editundo: Editundo(mp2); break;
case Idm_editcut: Editcut(mp2); break;
case Idm_editcopy: Editcopy(mp2); break;
case Idm_editpaste: Editpaste(mp2); break;
case Idm_editclear: Editclear(mp2); break;
case Idm_helpusinghelp: Helpusinghelp(mp2); break;
case Idm_helpgeneral: Helpgeneral(mp2); break;
case Idm_helpkeys: Helpkeys(mp2); break;
case Idm_helpindex: Helplndex(mp2); break;
case Idm_helpprodinfo: Helpprodinfo(mp2); break; /*
* Тут викликається призначена для користувача процедура
* обробки команд, щоб обробити ті id'
* які ще не були оброблені. */
default:
Usercammand(mpl, mp2); break; )
} /* Maincommand() */


Спеціальна програма менеджер подій (мал. 7.12)переглядає чергу і передає події, що поступають, обробникам. Події, пов'язані з екранними координатами, передаються обробникові, що асоціюється з відповідним вікном. Клавіатурні події передаються фокусу клавіатури — поточному активному обробникові клавіатури.
Управління подіями дозволяє відносно легко розробляти динамічні призначені для користувача інтерфейси, звичні для користувачів сучасних графічних оболонок.
Висока динамічність інтерфейсу найпростіше забезпечується, якщо кожен обробник швидко завершується. Якщо ж через природу запрошуваної операції вона не може завершитися швидко — наприклад, якщо ми вставили символ, параграф подовжився на рядок, і в результаті текстовому процесору Тіпа WYSIWYG доводиться переформатувати і переразбівать на страні-ци весь подальший текст — ми можемо зіткнутися з проблемою.

Мал. 7.12. Менеджер і обробники подій

У такій ситуації (а при написанні реальних застосувань вона виникає часто-густо) ми і вимушені задуматися про те, що ж насправді представляють собою обробники — процедури, що синхронно викликаються єдиною ниткою менеджера подій, або нитки, що паралельно виконуються. Перша стратегія називається синхронною обробкою повідомлень а друга, відповідно, — асинхронною.
Графічні інтерфейси першого покоління — Mac OS, Winl6 — реалізовували синхронну обробку повідомлень, а коли обробник замислювався надовго, малювали невід'ємний атрибут цих систем — курсор миші у формі пісочного годинника.
Декілька досконалішу архітектуру пропонує віконна підсистема Os/2, Presentation Manager. PM також реалізує синхронну стратегію обробки повідомлень (менеджер подій завжди чекає завершення чергового обробника), але в системі, окрім менеджера подій, можуть існувати і інші нитки. Якщо обробка події вимагає тривалих обчислень або інших дій (наприклад, звернення до зовнішніх пристроїв або до мережі), рекомендується створити для цього окрему нитку і продовжити обробку асихронно. Якщо ж додаток цей не зробить (наприклад, обробник події просто зациклиться або засне на семафорі), системна черга повідомлень буде заблокована і жодне з графічних застосувань не зможе працювати. Сучасні версії РМ надають в цьому випадку можливість відчепити "ненормальне" застосування від черги або пажі примусово завершити його.
Асинхронні черги повідомлень надають Win32 і віконна система X Window. Втім, і при асинхронній черзі однопоточний обробник подій, що впав у філософські роздуми, — теж малоприємне видовище, адже він не може перемальовувати власне вікно, тому пересування інших вікон по екрану породжує цікаві спецефекти (на жаль, зберегти ці ефекти за допомогою утиліт збереження екрану неможливо — всі відомі авторові засобу чекають, поки всі вікна, що попали в область, що зберігалася, перемальовуватимуться. А фотографії монітора зазвичай мають низьку якість). Розробникам додатків для названих систем також рекомендується виносити тривалі обчислення в окремі нитки.
Більшість реальних застосувань для сучасних ОС, що мають призначений для користувача інтерфейс, таким чином, мають двух- або більш слойную архітектуру. При цьому архітектура найближчого до користувача стоячи (frontend) як правило, тяжіє до подієво-керованій, а наступні шари (backend) зазвичай складаються з більш традиційних виконуються ниток, що взаємодіють (не завжди, втім, строго гармонійно) паралельно, частенько навіть рознесених по різних обчислювальних системах.


:: Реклама ::

 

:: Посилання ::


 

 

 


Copyright © Kivik, 2017