кладова контексту нитки включає її регістровий контекст (зокрема, вміст регістра лічильника команд) і динамічно створювані ядерні стеки.
Наведене коротке обговорення поняття нитки здається достатнім для того, щоб зрозуміти, що впровадження в ОС механізму легковагих процесів вимагає істотних переробок ядра системи. (Завжди важко впровадити в програму кошти, для підтримки яких вона не була спочатку пристосована.)
3.2.1 Підходи до організації ниток і управління ними в різних варіантах ОС UNIX
Хоча концептуально реалізації механізму ниток в різних сучасних варіантах практично еквівалентні (та й що особливе можна придумати по приводу легковагих процесів?), технічно і, на жаль, щодо інтерфейсів ці реалізації різняться. Ми не ставимо тут перед собою цілі описати в деталях-яку реалізацію, однак постараємося в загальних рисах охарактеризувати різні підходи.
Почнемо з того, що різноманітність механізмів ниток в сучасних варіантах ОС UNIX саме по собі представляє проблему. Зараз досить важко говорити про можливості мобільного паралельного програмування в середовищі UNIX-орієнтованих операційних систем. Якщо програміст хоче домогтися граничної ефективності (а він повинен цього хотіти, якщо для цілей його проекту придбаний дорогий мультипроцессор), то він змушений використовувати всі унікальні можливості використовуваної ним операційної системи.
Для всіх очевидно, що сьогоднішня ситуація далека від ідеальної. Однак, мабуть, її було неможливо уникнути, оскільки постачальники симетричних мультипроцесорних архітектур повинні були якомога раніше надати своїм покупцям можливості ефективного програмування, і часу на узгодження рішень просто не було (будь-яких постачальників насамперед цікавить обсяг продажів, а проблеми майбутнього залишаються на майбутнє).
Застосовувані в даний час підходи залежать від того, наскільки уважно розробники ОС ставилися до проблем реального часу. (Повертаючись до введення цього розділу, ще раз зазначимо, що тут ми маємо на увазі "м'яке" реальний час, тобто програмно-апаратні системи, які забезпечують швидку реакцію на зовнішні події, але час реакції не встановлено абсолютно строго.) Типова система реального часу складається з загального монітора, який відстежує загальний стан системи і реагує на зовнішні та внутрішні події, і сукупності обробників подій, які, бажано паралельно, виконують основні функції системи.
Зрозуміло, що від можливостей реального розпаралелювання функцій обробників залежать загальні часові показники системи. Якщо, наприклад, при проектуванні системи відмічено, що типовою картиною є "Одночасне" надходження в систему N зовнішніх подій, то бажано гарантувати наявність реальних N пристроїв обробки, на яких можуть базуватися обробники. На цих спостереженнях заснований підхід компанії Sun Microsystems. p> В системі Solaris (правильніше говорити SunOS 4.x, оскільки Solaris в термінології Sun представляє собою не операційну систему, а розширену операційну середу) прийнятий наступний підхід. При запуску будь-якого процесу можна зажадати резервування одного або декількох процесорів мультипроцессорной системи. Це означає, що операційна система не надасть ніякому іншому процесу можливості виконання на зарезервованому (их) процесорі (ах). Незалежно від того, чи готова до виконання хоча б одна нитка такого процесу, зарезервовані процесори не будуть використовуватися ні для чого іншого.
Далі, при утворенні нитки можна закріпити її за одним або кількома процесорами з числа зарезервованих. Зокрема, таким чином, в принципі можна прив'язати нитку до деякому фіксованому процесору. У загальному випадку деяка сукупність потоків управління прив'язується до деякої сукупності процесорів так, щоб середній час реакції системи реального часу задовольняло зовнішнім критеріям. Очевидно, що це "Асемблерний" стиль програмування (занадто багато перекладається на користувача), але зате він відкриває широкі можливості перед розробниками систем реального часу (які, щоправда, після цього залежать не тільки від особливостей конкретної операційної системи, але і від конкретної конфігурації даної комп'ютерної установки). Підхід Solaris переслідує мети задовольнити розробників систем "м'якого" (а, можливо, і "жорсткого") реального часу, і тому фактично дає їм в руки засоби розподілу критичних обчислювальних ресурсів.
В інших підходах більшою мірою переслідується мета рівномірної балансування завантаження мультипроцессора. У цьому випадку програміст не надаються кошти явною прив'язки процесорів до процесів або ниткам. Система допускає явне розпаралелювання в межах загальної віртуальної пам'яті і "Обіцяє", що в міру можливостей все процесори обчислювальної системи будуть завантажені рівномірно. Цей підхід забезпечує найбільш ефективне використання загальних обчислювальних ресурсів мультипроцессора, але не гарантує коректність виконання систем реального часу (якщо не вважат...
