Потоки в POSIX

Щоб надати можливість створення переносимих багатопоточних програм, щодо потоків інститутом IEEE був визначений стандарт - IEEE standard 1003.1с. Визначений у ній пакет, що стосується потоків, називається Pthreads. Він підтримується більшістю UNIX-систем. У стандарті визначено більше 60 викликів функцій. Опишемо ряд самих основних функцій.

Всі потоки Pthreads мають певні властивості._____________________________________________

____________________________________________________________________________________________________________________________________________________________________________________________

Таблиця 2.5. Ряд викликів функцій стандарту Pthreads

Вызовы, связанные с потоком	Описание
pthread_create	Создание нового потока
pthread_exit	Завершение работы вызвавшего потока
pthreadjoin	Ожидание выхода из указанного потока
pthread_yield	Освобождение центрального процессора, позволяющее выполняться другому потоку
pthread_attr_init	Создание и инициализация структуры атрибутов потока
pth read_attr_destroy	Удаление структуры атрибутов потока

 

Реалізація потоків у просторі користувача

Є два основних способи реалізації набору потоків:__________________________________________

________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

У всіх цих реалізацій одна і та ж загальна структура, показана на рис. 2.10, а

Рис. 2.10. Набір потоків на рівні користувача (а); набір потоків, керований ядром (б)

2.2.3 Реалізація потоків в ядрі

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

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

Для потоків, реалізованих на рівні ядра, не потрібно ніяких нових, неблокірующіх системних викликів. Більш того, якщо один з виконуваних пострумів зіткнеться з помилкою звернення до відсутньої сторінці, ядро ​​може з легкістю перевірити наявність у процесу будь-яких інших готових до виконання потоків, і при наявності таких, запустити один з них на виконання, поки триватиме очікування витягу запитаної сторінки з диска. Головний недолік цих потоків полягає в дуже істотних витратах часу на системний виклик, тому якщо операції над потоками (створення, видалення і т. п.) проводяться досить часто, то це тягне за собою більш суттєві витрати.

Хоча потоки, створювані на рівні ядра, і дозволяють вирішити ряд проблем, але впоратися з усіма існуючими проблемами вони не в змозі.

Що буде, наприклад, коли станеться розгалуження багатопотокового процесу? Чи буде у нового процесу стільки ж потоків, скільки було у старого, або буде тільки один потік?

Відповісти:

______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Іншою проблемою є сигнали. Варто згадати, що сигнали посилаються процесам, а не потокам, принаймні, так робиться в класичній моделі.

Який з потоків повинен обробити надходить сигнал? Може бути, потоки повинні зареєструвати свої інтереси в конкретних сигналах, щоб при посаді сигналу він передавався потоку, який заявив про свою зацікавленість у цьому сигналі? Тоді виникає питання: що буде, якщо на один і той же сигнал зареєструвалося два або більше двох потоків? І це тільки дві проблеми, створються потоками, а адже насправді їх значно більше.

Відповісти:

_______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

 

Гибридна реалізація

У спробах об'єднати переваги створення потоків на рівні користувача і на рівні ядра була досліджена маса різних шляхів. Один з них, заданний на рис. 2.11, полягає у використанні потоків на рівні ядра, а потім декількох потоків на рівні користувача в рамках деяких або всіх потоків на рівні ядра. ___________________________________________________________________________________________

________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Рис. 2.11. Поділ на користувальницькі потоки в рамках потоку ядра

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

 

Тема 2.3. Взаємодія процесів

Взаємодія процесів, або межпроцесну взаємодією - InterProcess Communication, або IPC.

Будуть розглянуті три питання.

Перший стосуватиметься вже згаданого прикладу: як один процес може передавати інформацію іншому процесу.

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

Третє питання стосуватиметься визначення правильної послідовності на основі існуючих взаємозалежностей: якщо процес А виробляє дані, а процес Б їх роздруковує, то процес Б, перед тим як друкувати, повинен почекати, поки процес А не виробить певні дані.

Слід зазначити, що два із цих трьох питань також застосовні і до потоків.

Перший з них, який стосується передачі інформації, стосовно до потокам вирішується значно легше, оскільки потоки мають загальний адресний простір (взаємодіючі потоки, реалізовані в різних адресних просторах, підпадають під категорію взаємодії процесів).

А от два інших питання щодо виключення взаємних перешкод і правильної послідовності в повній мірі застосовні і до потоків: подібні проблеми і подібні методи їх вирішення

Змагальна ситуація

Щоб подивитися, як взаємодія процесів здійснюється на практиці, розглянемо простий загальновідомий приклад - спулер друку. Коли процесу необхідно роздрукувати небудь файл, він поміщає ім'я цього файлу в спеціальний каталог спулера.

Інший процес під назвою демон принтера періодично веде перевірку наявності файлів для друку, і в тому випадку, якщо такі файли є, розпаковує їх і видаляє їх імена з каталогу.

Уявіть, що у нашому каталозі спулера є велика кількість областей пам'яті з номерами 0, 1, 2, ..., в кожній з яких може зберігатися ім'я файлу. Також уявіть, що є дві загальні змінні: out, яка вказує на наступний файл, призначений для друку, і т, яка вказує на наступну вільну область у каталозі. Ці дві змінні могли б непогано зберігатися у файлі, що складається з двох слів і доступному всім процесам. У якийсь момент часу області від 0 до 3 пустують (файли вже роздруковані). Майже одночасно процеси А і Б вирішують, що їм потрібно поставити файл в чергу на друк. Ця ситуація показана на рис. 2.15.

Рис. 2.15. Одночасне прагнення двох процесів отримати доступ до загальної пам'яті

У правовому просторі, де застосовні закони Мерфі, може статися таке. Процес А зчитує значення змінної in і зберігає значення 7 в локальній змінній по імені nextfreeslot (наступна вільна область). Відразу ж після цього відбувається переривання по таймеру, центральний процесор вирішує, що процес А пропрацював достатньо довго, і перемикається на виконання процесу Б. Процес Б також зчитує значення змінної in і також отримує число 7. Він також зберігає його в своїй локальній змінній next free slot. До поточного моменту обидва процеси вважають, що наступною доступною областю буде 7. Процес Б продовжує виконуватися. Він зберігає ім'я свого файлу в області 7 і привласнює змінної in оновлене значення 8. Потім він переходить до виконання якихось інших дій. Через деякий час виконання процесу Л поновлюється з того місця, де він був зупинений. Він зчитує значення зміної next free slot, бачить там число 7 і записує ім'я свого файлу в область 7, затираючи то ім'я файлу, яке тільки що було в нього поміщено процесом Б. Потім він обчислює next free slot + 1, отримує значення 8 , і привласнює його змінною in. В каталозі спулера немає внутрішніх суперечностей, тому демон друку не помітить ніяких вад, але процес Б ніколи не отримає виводу на друк.

Подібна ситуація, ______________________________________________________________________

__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Критичні області

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

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Якби вдалося все вибудувати таким чином, щоб ніякі два процеси не перебували одночасно в своїх критичних областях, це дозволило б уникнути змагань.

Хоча виконання цієї вимоги дозволяє уникнути змагальних ситуацій, його недостатньо для того, щоб паралельні процеси правильно вистраівалі свою спільну роботу і ефективно використовували загальні дані.

Для прийнятного рішення необхідне дотримання чотирьох умов:

___________________________________________________________________________________

1. ___________________________________________________________________________________

2. ___________________________________________________________________________________

3. ___________________________________________________________________________________

В абстрактному сенсі необхідне нам поведінку показано на рис. 2.16. Ми бачимо, що процес А входить в свою критичну область під час Т1. Трохи пізніше, коли настає час Т2, процес Б намагається увійти в свою критичну область, але зазнає невдачі, оскільки інший процес вже знаходиться у своїй критичній області, а ми допускаємо це в кожен момент часу тільки для одного процесу. Отже, Б тимчасово припиняється до настання часу Т3, коли А покине свою критичну область, дозволяючи Б тут же увійти в свою критичну область. З часом (в момент Т4) Б покидає свою критичну область, і ми повертаємося у вихідну ситуацію, коли жоден з процесів не знаходиться у своїй критичній області.

Рис. 2.16. Взаємне виключення використання критичних областей

 

Лекція №10