и можливості встановлення спеціальних пріоритетів реального часу).
Зазначимо існування ще однієї апаратно-програмної проблеми, пов'язаної з нитками (і не тільки з ними). Проблема пов'язана з тим, що в існуючих симетричних мультипроцесорах зазвичай кожен процесор має власної надшвидкодіючої буферноїпам'яттю (кешем). Ідея кешу, в загальних рисах, полягає в тому, щоб забезпечити процесору дуже швидкий (без необхідності виходу на шину доступу до спільної оперативної пам'яті) доступ до найбільш актуальних даними. Зокрема, якщо програма виконує запис в пам'ять, то це дія не обов'язково відразу відображається у відповідному елементі основної пам'яті; до пори до часу змінений елемент даних може міститися тільки в локальному кеші того процесора, на якому виконується програма. Звичайно, це суперечить ідеї спільного використання віртуальної пам'яті нитками одного процесу (а також ідеї використання пам'яті, що розділяється між декількома процесами).
Це дуже складна проблема, що відноситься до області проблем "Когерентності кешей". Теоретично є багато підходів до її рішенню (наприклад, апаратне розпізнавання необхідності виштовхування записи з кешу з синхронним оголошенням недійсним змісту всіх кешей, включають той же елемент даних). Однак на практиці такі складні дії не застосовуються, і звичайним прийомом є скасування режиму кешування в тому випадку, коли на різних процесорах мультипроцессорной системи виконуються нитки одного процесу або процеси, що використовують пам'ять, що розділяється.
Після введення поняття нитки трансформується саме поняття процесу. Тепер краще (і правильніше) розуміти процес ОС UNIX як деякий контекст, що включає віртуальну пам'ять та інші системні ресурси (включаючи відкриті файли), в якому виконується, принаймні, один потік управління (нитка), що володіє своїм власним (більш простим) контекстом. Тепер ядро ​​знає про існування цих двох рівнів контекстів і здатне порівняно швидко змінювати контекст нитки (не зраджуючи загального контексту процесу) і так само, як і раніше, змінювати контекст процесу. Останнє зауваження відноситься до синхронізації виконання ниток одного процесу (точніше було б говорити про синхронізацію доступу ниток до загальних ресурсів процесу - віртуальної пам'яті, відкритим файлів і т. д.). Звичайно, можна користуватися (порівняно) традиційними засобами синхронізації (наприклад, семафорами). Однак виявляється, що система може надати для синхронізації ниток одного процесу дешевші засоби (оскільки всі нитки працюють в загальному контексті процесу). Зазвичай ці засоби належать до класу засобів взаємного виключення (тобто до класу семафороподобних засобів). На жаль, і в цьому відношенні до теперішнього часу відсутня будь стандартизація. p> 3.3 Семафори
Підтримка операційної системи в багатопроцесорної конфігурації може включати в себе розбиття ядра системи на критичні ділянки, паралельне виконання яких на декількох процесорах не допускається. Нижченаведені міркування допомагають зрозуміти суть даної особливості. При найближчому розгляді відразу ж виникають два питання: як використовувати семафори і де визначити критичні ділянки.
Якщо при виконанні критичного ділянки програми процес призупиняється, для захисту ділянки від посягань з боку інших процесів алгоритми роботи ядра однопроцесорній операційної системи використовують блокування.
Механізм встановлення блокування:
/* операція перевірки */p> виконувати поки (Блокування встановлена)
{
призупинитися (до зняття блокування);
};
встановити блокування;
Механізм зняття блокування:
зняти блокування;
вивести з стану приостанова всі процеси, припинені в результаті блокування;
Блокування такого роду охоплюють деякі критичні ділянки, але не працюють в багатопроцесорних системах, що видно з наведеного малюнка:
В
br/>
Припустимо, що блокування знята, і що два процеси на різних процесорах одночасно намагаються перевірити її наявність і встановити її. У момент t вони виявляють зняття блокування, встановлюють її знову, вступають в критичний ділянку і створюють небезпеку порушення цілісності структур даних ядра. У умови одночасності є відхилення: механізм не спрацює, якщо перед тим, як процес виконує операцію перевірки, жоден інший процес не виконав операцію встановлення блокування. Якщо, наприклад, після виявлення зняття блокування процесор A обробляє переривання і в цей момент процесор B виконує перевірку і встановлює блокування, по виході з переривання процесор A так само встановить блокування. Щоб запобігти виникненню подібної ситуації, потрібно зробити так, щоб процедура блокування була неподільною: перевірку наявності блокування і її установку слід об'єднати в одну операцію, щоб у кожен момент часу з блокуванням мав справу тільки один процес.
<...
