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

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

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

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

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

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

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

Активація планувальника

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

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

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

При використанні активації планувальника коли ядро знає, що потік заблокований (наприклад, за рахунок виконання блокуючого системного виклику або виникнення помилки звернення до неіснуючої сторінки), воно повідомляє приналежну процесу систему підтримки виконання програм, передаючи через стек в якості параметрів номер даного потоку і опис події. Повідомлення здійснюється за рахунок того, що ядро активує систему підтримки виконання програм із заздалегідь відомої стартової адреси, - приблизно так само, як діють сигнали в UNIX. Цей механізм називається upcall (викликом наверх).

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

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

Недоліком активацій планувальника є повна залежність цієї технології від викликів наверх (upcall) - концепції, що порушує структуру, властиву будь багаторівневій системі.