Google розпочав відкриття реалізації моделі потоків M:N

компанія Google запропонувала для включення до складу ядра Linux перший набір патчів з реалізацією компонентів, необхідних забезпечення роботи моделі потоків M:N. Ініціатива Google пов'язана з відкриттям API, що розвивався за зачиненими дверима SwitchTo для ядра Linux, що забезпечує роботу реалізованої в просторі користувача багатопотокової підсистеми, що застосовує модель потоків M:N. Підсистема використовується в Google для забезпечення сервісів, що вимагають мінімальних затримок. Планування та управління розподілом потоків здійснюється цілком у просторі користувача, що дозволяє суттєво знизити кількість операцій перемикання контексту за рахунок мінімізації виконання системних викликів.

Для забезпечення роботи зазначеної підсистеми на рівні ядра Linux було реалізовано API SwitchTo, що пропонує три базові операції - wait, resume та swap (перемикання). Для включення до складу ядра запропоновано код нової операції FUTEX_SWAP, яка доповнює FUTEX_WAIT та FUTEX_WAKE, та надає основу для створення багатопотокових бібліотек у просторі користувача. FUTEX_SWAP також може застосовуватися для передачі повідомлень між завданнями за аналогією з RPC. Наприклад, в даний час для передачі повідомлення між завданнями потрібно виконати як мінімум чотири виклики FUTEX_WAIT і FUTEX_WAKE, використання FUTEX_SWAP дозволить обійтися однією операцією, яка буде виконана в 5-10 разів швидше.

Google розпочав відкриття реалізації моделі потоків M:N

В даний час на практиці застосовуються в основному моделі потоків 1:1 та N:1. Модель 1:1 використовується в NPTL (POSIX потоки) та LinuxThreads, і має на увазі пряме зіставлення потоку у просторі користувача з потоком (одиницею планування виконання) лише на рівні ядра. Модель N:1 реалізована в GNU Pth, виносить диспетчеризацію потоків у простір користувача і дозволяє N потоків у просторі користувача прив'язати до одного потоку в ядрі, при цьому ядро ​​не має інформації про потоки користувача.

Основним недоліком моделі 1:1 є великі накладні витрати на перемикання контексту між ядром та простором користувача. Модель N:1 вирішує цю проблему, але створює нову - оскільки потік в ядрі є неподільною одиницею планування виконання, то потоки користувача, прив'язані до одного потоку в ядрі операційної системи, не можуть масштабуватися по ядрах CPU і виявляються прив'язаними до одного ядра CPU.

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

Джерело: opennet.ru

Додати коментар або відгук