8. Керування потоками в Linux

8.1. Базова підтримка багато потоковості

Донедавна єдиним засобом підтримки багатопотоковості в ядрі Linux був системний виклик clone( ), який дає можливість створити новий процес на базі наявного. Цей виклик багато в чому схожий на виклик fork( ), але має кілька особливостей.

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

♦ Для нового процесу потрібно задати новий стек (оскільки внаслідок виклику clone( ) два процеси можуть спільно використовувати загальну пам’ять, для них неприпустиме використання загального стека).

Підтримка clone ( ) означає реалізацію багатопотоковості за схемою 1:1. При цьому первинними в системі є процеси, а не потоки (у Linux послідовності інструкцій процесора, з якими працює ядро, називають процесами, а не потоками ядра).

Традиційна реалізація багатопотоковості в Linux визначає, що потоки користувача відображаються на процеси в ядрі. Тому недоцільно розглядати окремо структури даних потоку в Linux — він відображається такою ж самою структурою task_struct, як і процес.

Бібліотека підтримки потоків LinuxThreads

Безпосередньо використовувати системний виклик clone( ) для створення багатопотокових застосувань складно. Крім того, таке використання веде до втрати здатності до перенесення застосувань (виклик cl one() реалізований тільки в Linux і не є частиною POSIX). Для того щоб прикладний програміст міг використати у своїх програмах потоки POSIX, необхідна реалізація цього стандарту в бібліотеці підтримки потоків.

Основною бібліотекою підтримки потоків у Linux довгий час була бібліотека LinuxThreads. У ній підтримуються ті можливості стандарту POSIX.lb, які реалізуються на основі виклику clone( ). На жаль, через обмеженість цього виклику бібліотеці властиві об’єктивні недоліки, які ми розглянемо докладно.

Недоліки традиційної підтримки багатопотоковості в Linux

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

Таке використання системи висунуло до реалізації багатопотоковості вимоги високої надійності та масштабованості. Стало очевидно, що реалізація, заснована на системному виклику clone( ), цим вимогам не відповідає. Назвемо деякі причини цієї невідповідності.

♦ Оскільки потоки, створені за допомогою clone( ), фактично були процесами, що спільно використовують ресурси, створення кожного потоку збільшувало кількість процесів у системі.

♦ Кожний потік у системі, будучи за своєю суттю процесом, мав власний ідентифікатор процесу (pid), що не відповідало стандарту POSIX. Крім того, якщо потік створював інший потік, між ними виникав зв’язок «предок-нащадок», тоді як всі потоки мають бути рівноправними.

♦ Кожне багатопотокове застосування користувача обов’язково створювало додатковий потік (потік-менеджер), який відповідав за створення та знищення потоків і перенаправляв їм сигнали. Наявність такого потоку знижувала надійність і масштабованість системи (наприклад, у разі аварійного завершення потоку-менеджера застосування залишалося у невизначеному стані).

Усі ці фактори робили багатопотоковість у Linux швидше цікавим полем для експериментів, аніж реальним засобом підвищення продуктивності й масштабованості застосувань. Розв’язати всі проблеми шляхом усунення недоліків clone( ) і LinuxThreads виявилося неможливим, потрібне було повне перероблення засобів реалізації багатопотоковості в ядрі та створення нової бібліотеки підтримки потоків.