Стандарти CORBA

Стандарт CORBA

CORBA це стандарт для розподіленого кросплатформного обєктно-оріє­нтованого програмування. Вище згадувалося про застосування CORBA для під­т­римки паралелізму, оскільки реалізації стандарту CORBA можна використову­вати для розробки мультиагентних систем. Мультиагентні системи пропонують важливі мережеві моделі розподіленого програмування з рівноправними вузла­ми (peer-to-peer). В мультиагентних системах робота може бути організована паралельно. Це одна із областей, в яких паралельне та розподілене програмува­ння перетинаються. Незважаючи на те що агенти виконуються на різних ком­п’ю­терах, тобто агенти спільно працюють над однією спільною проблемою. Стандарт CORBA забезпечує відкриту, незалежну від виробника архітектуру та інфраструктуру, яку комп’ютерні додатки використовують для спільного вико­ристання в мережі. Використовуючи стандартний протокол ІІОР (Internet InterORB Protocol – протокол, який визначає передачу повідомлень між мереже­вими об’єктами по ТСР/ІР), CORBA- орієнтована програма (створена довіль­ним виробником на довільній мові програмування, яка виконується практично на довільному комп’ютері під керуванням довільної операційної системи в до­ві­льній мережі) може взаємодіяти з іншою CORBA- орієнтованою програмою (створеної тим же або іншим виробником на довільній мові програмування, яка виконується практично на довільному комп’ютері під керуванням операційної системи в довільній мережі). В наших лекціях використовується МІСО- реаліза­цію стандарту CORBA. МІСО – реалізація стандарту CORBA, яка вільно поши­рюється і повністю відповідає його вимогам.

14. Три рівні паралелізму в комп’ютерній програмі.

В наших лекціях ми досліджуємо можливість паралелізму в межах дода­тку (на відміну паралелізму на рівні операційної системи або апаратних засо­бів). Не дивлячись на те що паралелізм на рівні операційної системи або апарат­них засобі підтримує паралелізм додатку, ми все ж будемо орієнтуватися на сам додаток. Отже, паралелізм можливо забезпечити на рівні:

· інструкції;

· підпрограми (функції, процедури);

· об’єктів;

· додатків.

Паралелізм на рівні інструкцій

Паралелізм на рівні інструкцій виникає, якщо декілька частин однієї інс­трукції можуть виконуватися одночасно. На рис. 4. показано приклад декомпо­зиції однієї інструкції з метою досягнення паралелізму окремих операцій. Ми бачимо що компонент (А + В) можемо обчислювати одночасно з компонентом (C + D). Даний вид паралелізму як правило підтримується компіляторами і не підпадає під керування програміста на мовах високого рівня.

Паралелізм на рівні підпрограм

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

Паралелізм на рівні об’єктів

ДЗС-структуру програмного рішення можемо розподілити між об’єкта­ми. Кожен об’єкт можна призначити окремому потоку або процесу. Використо­вуючи стандарт CORBA (Common Object Request Broker Architecture – техноло­гія створення розподілених об’єктних додатків), всі об’єкти можна призначити різним комп’ютерам однієї мережі або різним комп’ютерам різних мереж. Об’є­кти, реалізовані в різних потоки або процесах, можуть виконувати свої ме­тоди паралельно.

Паралелізм на рівні додатків

Декілька додатків можуть спільно розв’язувати певну проблему. Не див­лячись на те що певний додаток спочатку призначався для виконання окремої задачі, принципи багаторазового використання коду дозволяють додаткам спів­працювати. В таких випадках два окремих випадки ефективно працюють спіль­но подібно єдиному розподіленому додатку. Наприклад буфер обміну (Clip­board) не передбачався для роботи ні з яким конкретним додатком, але його успішно використовують багато додатків робочого столу. Про деякі варіанти застосування буфера обміну його творці в процесі розробки і не мріяли.

Другий та третій рівні – це основні рівні паралелізму, тому методам їх реалізації і приділяється основна увага в курсі лекцій. Рівня операційної систе­ми та апаратних засобів ми торкнемося тільки втому випадку, коли це буде нео­бхідно в контексті проектування додатку. Отримавши відповідну ДЗС-структу­ру для проекту, який передбачає паралельні та розподілені програмування, мо­жемо переходити до наступного етапу – розглянемо можливості його реалізації.

15. Проблема зв’язку та синхронізації в паралельному програмуванні.

Для координації задач, які виконуються паралельно, необхідно забезпе­чити зв'язок між ними та синхронізацію їх робіт. При некоректному зв’язку або синхронізації як правило виникають чотири проблеми.

Проблема № 1: ²гонкі² даних

Якщо декілька задач одночасно спробують деяку загальну область да­них, але кінцеве значення даних при цьому буде залежати від того, яка задача звернулася до цієї області першою, виникне ситуація, яку називають станом ² гонок ² (race codition). У випадку, коли декілька задач спробує обновити один і той же ресурс даних, такий стан ²гонок² називають ² гонкою ² даних (data race). Яка задача в нашій програмі підтримки електронного банку першою отримає доступ до залишку на рахунку, визначається результатом роботи плануваль­ни­ка задач операційної системи, станом процесорів, часом очікування та випадко­вими причинами. В такій ситуації створюється стан ²гонок². Яке значення в цьо­му випадку повинен повідомити банк в якості реального залишку на рахун­ку?

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

Проблема № 2: нескінченне відтермінування

Таке планування, при якому одна або декілька задач повинні очікувати до тих пір, доки не відбудеться деяка подія або не створяться певні умови, може виявитися доволі не простим. По-перше, очікувана подія або умова повинні ви­різнятися регулярністю. По-друге, між задачами необхідно налагодити зв'язок. Якщо одна або декілька задач очікують сеансу зв’язку до свого виконання, то у випадку, якщо очікуваний сеанс зв’язку не відбудеться, відбудеться надто пізно або не повністю, ці задачі можуть так ніколи і не виконатися. І також, якщо очі­кувана подія або умова, яка (за нашою думкою) повинна відбутися (або насту­пити), але в дійсності не відбулася (або не наступила), то зупинені нами задачі будуть вічно знаходитися в стані очікування. Якщо ми призупинимо одну або декілька задач до настання події (або умови), яка ніколи не відбудеться, вини­к­не ситуація, що називається нескінченне відтермінування (indefinite postpone­ment). Повертаючись до нашого прикладу електронного банку, приймаємо, що, якщо ми встановимо правила, які вказують всім задачам зняття грошей з рахун­ку знаходиться в стані очікування до тих пір, доки не будуть виконані всі задачі вкладання грошей на рахунок, то задачі знаття грошей ризикують стати нескін­ченно відкладеними.

Ви виходили з припущення про гарантоване існування задач вкладання грошей на рахунок. Але якщо один із запитів на поповнення рахунків не надій­де, то що тоді заставить виконатись задачі зняття грошей? І, навпаки, що, якщо будуть нескінченно надходити запити на поповнення одного і того ж рахунку? Тоді не зможе пройти до рахунку ні один запит на зняття грошей. Така ситуація також може викликати нескінчену відтермінування задач зняття грошей.

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

Проблема № 3: взаємне блокування

Взаємне блокування – це ще одна проблема, пов’язана з очікуванням. Для демонстрації взаємного блокування в важитимемо, що в нашій програмі підтримку електронного банку три задачі працюють не з одним, а з двома раху­нками. Згадаємо, що задача А отримує запит від задачі В на знімання грошей з рахунку, А від задачі С – запити на вкладання грошей на депозит. Задачі А, В і С можуть виконуватися паралельно. Однак задачі В і С можуть оновлювати од­ночасно тільки один рахунок. Задача А надає доступ задач В і С до необхідного рахунку за правилом ²першим прийшов – перший пішов². Вважаємо, що задача В має монопольний доступ до рахунку 1, а задача С – монопольний доступ до рахунку – 2. При цьому задачі В для виконання відповідної обробки також нео­бхідний доступ до рахунку 2 і задачі С – доступ до рахунку 1. Задача В утримує рахунок 1, очікуючи, доки задача С не звільнить рахунок 1. Тим самим задачі В і С ризикують попасти в безвихідну ситуацію, яку в даному випадку можемо назвати взаємним блокуванням (deadlock). Ситуація взаємного блокування між задачами В і С схематично подано на рис. 3.

Форма взаємного блокування в даному випадку пояснюється наявністю задач, що виконуються паралельно, мають загальний доступ до даних, що вико­ристовуються спільно, і які їм дозволено оновлювати. Тут можлива ситуація, коли кожна із задач буде очікувати до тих пір, доки друга не звільнить доступ ло загальних даних (Загальними даними тут є рахунок 1 і рахунок 2). Обидві задачі мають доступ до двох рахунків. Може статися так, що замість отримання доступу однієї задачі до двох рахунків, кожна задача отримає доступ до одного з рахунків. Оскільки задача В не може звільнити рахунок 1, доки не отримає доступу до рахунку 2, а задача С не може звільнити рахунок 2, доки не отримає доступу до рахунку 1, програма обслуговування рахунків електронного банку буде залишатися заблокованою. Зверніть увагу, що задачі В і С можуть ввести в стан нескінченого відтермінування і інші задачі (якщо такі є в системі). Якщо інші задачі очікують доступу до рахунків 1 або 2, а задачі В і С зв’язані взаєм­ним блокуванням. При координації задач, які виконуються паралельно необхід­но пам’ятати, що взаємне блокування і нескінченне відтермінування – це самі
небезпечні перепони, які необхідно передбачити і уникнути.

Проблема № 4: труднощі організації зв’язку

Багато поширених паралельних середовищ (наприклад, кластери) в біль­шості випадків складаються з гетерогенних комп’ютерних мереж. Гетерогенні комп’ютерні мережі – це системи, які складаються з комп’ютерів різних типів, що працюють в загальному випадку під керуванням різних операційних систем і використовуються різні мережеві протоколи. Їх процесори можуть мати різну архітектуру, опрацьовувати слова різної довжини і використовувати різні ма­ши­нні мови. Окрім різних операційних систем, комп’ютери можуть відрізня­ти­ся стратегіями планування і системами пріоритетів. Гірше всього, всі системи можуть розрізнятися параметрами передачі даних. Це робить обробку помилок та виключних ситуацій (виключень) особливо складною. Неоднорідність сис­теми може ускладнюватись і іншими причинами. Наприклад, може виникнути необхідність в організації спільного використання даних програм, написаних на різних мовах, або розроблених з використанням різних моделей ПЗ. Адже за­га­льне системне рішення може бути реалізовано по частинах, написаних на мовах Ада, С++ і Java. Це вносить проблеми міжмовного зв’язку. І навіть, якщо розпо­ділена або паралельна система не є гетерогенною, залишається проблема взає­модії між декількома процесами або потоками. Оскільки кожен процес має вла­сний адресний простір, то для спільного використання змінних, параметрів та значень, які повертаються функціям, необхідно застосувати технологію між процесорної взаємодії (interprocess communication - IPC), або МПВ- технологію. І хоча реалізація МПВ- методів необов’язково є самою складною частиною роз­робки системи ПЗ, тим не менше вони створюють додатковий рівень проекту­вання, тестування і налагодження в створенні системи.

16. POSIX-специфікація: п’ять базових механізмів.

POSIX- специфікація підтримує п’ять базових механізмів, які викорис­то­вуються для реалізації взаємодії між процесами:

· файли з засобами блокування та розблокування;

· канали (неіменовані, іменовані і черги FIFO);

· загальна пам'ять і повідомлення;

· сокети;

· семафори.

Кожен з цих механізмів має переваги, недоліки, складні питання глухі кути які проектувальники і розробники ПЗ повинні обов’язково враховувати, якщо хочуть створити надійний і ефективний зв'язок між декількома процесами. Організувати взаємодію. між декількома потоками (які інколи називають полегшеними процесами) зазвичай простіше, ніж між процесами, оскільки потоки використовують загальний адресний простір. Це означає, що кожен поті в програмі може легко передавати параметри, приймати значення, які повертаються функціями, і отримувати доступ до глобальних даних. Але якщо взаємодію процесів або потоків не спроектовано відповідним чином, ви­ни­кають такі проблеми, як взаємне блокування, нескінчені відтермінування та інші ситуації ²гонок² даних. Необхідно зауважити, що подані вище проблеми характерні як для розподіленого, так і для паралельного програмування.

Не дивлячись на те що системи з виключно паралельною обробкою від­різняються від систем з виключно розподіленою обробкою, ми зумисне не про­водили межі між проблемами координації в розподілених і паралельних систе­мах. Частково це пояснюється деяким перекриттям існуючих проблем, і частко­во тим, що деякі рішення проблем в одній області часто можемо використати для вирішення в іншій. Але головна причина ²узагальненого² підходу полягає в тому, що в наш час гібридні (паралельно-розподілені) системи стають загально­вживаними. Сучасний стан паралельній обробці даних визначають кластери і мережі. Унікальні кластерні конфігурації реалізують з готових продуктів. Такі архітектури містять колекцію комп’ютерів з багатьма процесорами, а одно про­цесорні системи відходять в минуле. В майбутньому передбачається, чисто роз­поділені системи будуть вбудовані у вигляді комп’ютерів з декількома проце­со­рами. Це означає, що на практиці проектувальник або розробник ПЗ буде те­пер все частіше стикатися з проблемами розподілу та паралелізму. Тому ми розглядаємо всі ці проблеми в одному просторі. В табл. 1. подано комбінації па­ралельного та розподіленого програмування з різними конфігураціями апара­т­ного забезпечення.

В табл.1 зверніть увагу на те, що існують конфігурації, в яких парале­лізм досягається за рахунок використання декількох комп’ютерів. В такому ви­падку ефективніше скористатися бібліотеками PVM. І також існують конфігу­ра­ції, в яких розподілене програмування може бути реалізоване лише на одно­му комп’ютері за рахунок розподілу логіки ПЗ на декілька процесів або пото­ків. Власне факт використання множини процесів або потоків говорить про те, що робота програми являє ²розподілений² характер. Комбінації паралельного і розподіленого програмування, подані в табл.1, показують, що проблеми конфі­гурації, за звичай характерні розподіленому програмуванню, можуть виникну­ти в ситуаціях, обумовлених паралельним програмування, і, навпаки, проблеми конфігурації, за звичай пов’язані з паралельним програмуванням, можуть ви­ни­­кати в ситуаціях, обумовлених розподіленим програмуванням.

Таблиця 1.	Комбінації паралельного і розподіленого програмування з різними конфігураціями апаратного забезпечення
	Один комп’ютер	Багато комп’ютерів
Паралельне програму­­­­- вання	Мітить багато процесорів. Ви­ко­­ристовує логічне розділен­ня на декілька потоків або про­це­сів. Потоки або процеси можуть виконуватися на різних проце­со­рах. Для координації задач не­обхідно МПВ- технології	Використовує такі бібліотеки, як PVM. Потребує організації взаємодії за допомогою передачі повідомлень, що як правило характерно для розподіленого програмування.
Розподілене програму-вання	Наявність декількох процесорів не є обов’язковим. Логіка ПЗ мо­же бути розділена на декіль­ка процесів або потоків	Реалізується за допомогою со­кетів і таких компонентів, як CORBA ORB (Object Request Broker – брокер об’єктних за­питів). Ми можемо використо­вувати тип взаємодії, який як правило пов'язаний з парале­льним програмуванням

Незалежно від конфігурації апаратних засобів, які використовуються, існує два базових механізми, що забезпечують взаємодію декількох задач: за­гальна пам'ять (пам’ять, що поділяється) і засоби передачі повідомлень. Для ефективного використання механізму загальної пам’яті програмісту необхідно передбачити рішення проблеми ²гонки² даних, взаємне блокування і нескінчене відтермінування. Схема передачі повідомлень повинна передбачати виникнення таких проблеми, як повідомлення, що перериваються, спотворені повідомлення, втрата інформації, помилкові повідомлення, надто довгі повідомлення, пору­ше­ння термінів повідомлення, дочасні повідомлення.

17. Основні архітектури ПЗ для паралельного та розподіленого програмуван­ня.

18. UML-діаграми для створення багатопоточних паралельних та розподілених програм.

19. Два види процесів.

20. Блок керування процесами.

21. Анатомія процесу.

22. Стани процесу.

23. Планування процесу, стратегії планування.

24. Встановлення та отримання пріоритету процесу.

25. Перемикання контексту.

26. Відношення між батьківським та дочірніми процесами.

27. Читання та встановлення змінних середовища.

28. Породження процесів.

29. Завершення процесу.

30. Ресурси процесу, типи ресурсів.

31. Асинхронні та синхронні процеси.

32. Розбиття програми на задачі.

33. Визначення потоку.

34. Контекстні вимоги до потоку.

35. Переваги використання потоків.

36. Недоліки використання потоків.

37. Анатомія потоку.

38. Атрибути потоку.

39. Планування потоків.

40. Стани потоків.

Дата добавления: 2015-05-07