Реалізація потоків в просторі користувача

Якщо розмістити потоки в просторі користувача то ядро нічого не знатиме про існування потоків, воно керуватиме звичайними, однопотоковими процесами.

Перша і найочевидніша перевага полягає в тому, що набір потоків на рівні користувача може бути реалізований в операційній системі, яка не підтримує потоки.

Потоки запускаються поверх системи підтримки виконання програм (run-time system), яка являє собою набір процедур, керуючих потоками. Чотири з них ми вже розглянули, це pthread_create, pthread_еxit, pthread_joinі pthread_yield, але зазвичай в наборі є ще й інші процедури.

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

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

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

Ще одною перевагою реалізації потоків на рівні користувача є можливість надати кожному процесу свої власні налаштування алгоритму планування.

Проблеми пов’язані з роботою потоків в просторі користувача:

1. Складність реалізації блокуючи системних викликів. Уявіть, що потік зчитує інформацію з клавіатури перед натисканням якої-небудь клавіші. Ми не можемо дозволити потоку здійснити справжній системний виклик, оскільки це зупинить виконання всіх потоків. Всі системні виклики можуть бути змінені і перетворені в неблокуючі (наприклад, зчитування з клавіатури буде просто повертати нуль байтів, якщо в буфері на даний момент відсутні символи), але це передбачає внесення змін в ОС та великої кількості користувацьких програм. Існує можливість створити код (конвертор, оболонка), який поміщається навколо системного виклику і який буде здійснювати перевірки, чи буде даний системний виклик блокуючим. Якщо виклик блокуючий, бібліотечна процедура read може бути замінена новою процедурою, яка спочатку здійснює виклик процедури select і тільки потім - виклик read, якщо він безпечний (тобто не буде здійснювати блокування). Якщо виклик read буде блокуючим, цей виклик не здійснюється. Замість цього запускається виконання іншого потоку. Наступного разу, коли система підтримки виконання програм отримує управління, вона може знову перевірити, чи буде на цей раз виклик read безпечний.

2. При виконанні блокування ядро, яке нічого не знає про потоки здійснює блокування всього процесу а не лише певного потоку. (відсутність сторінки в пам’яті).

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

4. Інший найбільш сильний аргумент проти потоків, реалізованих на рівні користувача, полягає в тому, що програмістам потоки звичайно потрібні саме в тих додатках, де вони часто блокуються, як, наприклад, в багатопотоковому веб-сервері. Ці потоки часто здійснюють системні виклики. Як тільки для виконання системного виклику ядро здійснить перехоплення управління, то йому не складе особливих труднощів зайнятися перемиканням потоків, якщо колишній потік заблокований.