формацію, ядро ​​змінює стан нитки з "чекає" на "Готова" і повертає її в чергу. Нитка виконується, коли з'являється можливість.
Хоча це пояснення поверхово, воно все ж показує, наскільки складним для операційної системи виявляється керування синхронізацією декількох процесів. У міру додавання нових процесорів до системи накладні витрати на управління конфліктами зростають, і це зменшує віддачу від ОС, орієнтованих на симетрично-багатопроцесорну обробку.
В
3.2 Нитки (Threads)
Поняття "легковагого процесу" (light-weight process), або, як прийнято називати його в сучасних варіантах ОС, "thread" (нитка, потік управління) давно відомо в області операційних систем. Інтуїтивно зрозуміло, що концепції віртуальної пам'яті і потоку команд, що виконується в цієї віртуальної пам'яті, в принципі, ортогональні. Ні з чого не випливає, що однієї віртуальної пам'яті повинен відповідати один і тільки один потік управління. Тому, наприклад, в ОС Multics допускалося (і було прийнятої практикою) мати довільну кількість процесів, які виконуються в загальній (Що розділяється) віртуальної пам'яті. p> Зрозуміло, що якщо кілька процесів спільно користуються деякими ресурсами, то при доступі до цих ресурсів вони повинні синхронізуватися (Наприклад, з використанням семафорів, див. розділ "Семафори"). Багаторічний досвід програмування з використанням явних примітивів синхронізації показав, що цей стиль "паралельного" програмування породжує серйозні проблеми при написанні, налагодженні і супроводі програм (найбільш важко виявляються помилки в програмах зазвичай пов'язані з синхронізацією). Це стало однією з причин того, що в традиційних варіантах ОС поняття процесу жорстко пов'язувалося з поняттям окремої і недоступною для інших процесів віртуальної пам'яті. Кожен процес був захищений ядром операційної системи від неконтрольованого втручання інших процесів. Багато років це вважалося одним з основних достоїнств системи (втім, це думка існує і сьогодні).
Однак зв'язування процесу з віртуальною пам'яттю породжує, по крайней заходу, дві проблеми. Перша проблема пов'язана з так званими системами реального часу. Такі системи, як правило, призначені для одночасного управління декількома зовнішніми об'єктами і найбільш природно представляються у вигляді сукупності "паралельно" (або "квазіпараллельний") виконуваних потоків команд (тобто взаємодіючих процесів). Однак якщо з кожним процесом пов'язана окрема віртуальна пам'ять, то зміна контексту процесора (тобто його перемикання з виконання одного процесу на виконання іншого процесу) є відносно дорогою операцією. Тому традиційний підхід перешкоджав використанню системи в додатках реального часу.
Другий (і може бути більш істотною) проблемою стала поява так званих симетричних мультипроцесорних комп'ютерних архітектур (SMP - Symmetric Multiprocessor Processing). У таких комп'ютерах фізично присутні кілька процесорів, які мають однакові за швидкістю можливості доступу до спільно використовуваної основної пам'яті. Поява подібних машин на світовому ринку, природно, вивело на перший план проблему їх ефективного використання. Зрозуміло, що при застосуванні традиційного підходу до організації процесів від наявності загальної пам'яті не дуже багато толку (хоча при наявності можливостей розділяється пам'яті про це можна сперечатися). До моменту появи SMP з'ясувалося, що технологія програмування все ще не може запропонувати ефективного і безпечного способу реального паралельного програмування. Тому довелося повернутися до явного паралельного програмуванню з використанням паралельних процесів в загальній віртуальній (а тим самим, і основний) пам'яті з явною синхронізацією.
Що ж розуміється під "ниткою" (thread)? Це незалежний потік управління, що виконується в контексті деякого процесу. Фактично, поняття контексту процесу змінюється наступним чином. Все, що не відноситься до потоку управління (віртуальна пам'ять, дескриптори відкритих файлів і т. д.), залишається в загальному контексті процесу. Речі, які характерні для потоку управління (Регістровий контекст, стеки різного рівня і т. д.), переходять з контексту процесу в контекст нитки. Загальна картина показана на малюнку:
В
p> Як видно з цього малюнка, всі нитки процесу виконуються в його контексті, але кожна нитка має свій власний контекст. Контекст нитки, як і контекст процесу, складається з користувальницької та ядерної складових. Призначена для користувача складова контексту нитки включає індивідуальний стек нитки. Оскільки нитки одного процесу виконуються в загальній віртуальної пам'яті, всі нитки процесу мають рівні права доступу до будь-яких частин віртуальної пам'яті процесу, стек (сегмент стека) будь нитки процесу в принципі не захищений від довільного (Наприклад, з причини помилки) доступу з боку інших ниток. Ядерна с...
