Нещодавно я чув, як мало хто говорить, що в Linux майже завжди краще використовувати процеси замість потоків, оскільки Linux дуже ефективний в обробці процесів і тому, що існує багато таких проблем (як блокування), пов'язаних з потоками. Однак я підозріло, тому що, здається, нитки можуть дати досить великий приріст у деяких ситуаціях.

Отже, моє запитання полягає в тому, що, якщо стикатися з ситуацією, коли нитки та процеси можуть досить добре впоратися, я повинен використовувати процеси чи нитки? Наприклад, якщо я писав веб-сервер, чи слід використовувати процеси або потоки (або комбінацію)?

Linux використовує модель різьблення 1-1, при цьому (до ядра) немає різниці між процесами та потоками - все це просто виконується завдання. *

У Linux системний виклик cloneклонує завдання із налаштованим рівнем спільного доступу, серед яких:

• CLONE_FILES: спільний доступ до тієї ж таблиці дескрипторів файлів (замість створення копії)
• CLONE_PARENT: не встановлюйте стосунки батько-дитина між новим завданням і старим (інакше дитина getppid()= батько getpid())
• CLONE_VM: спільний обсяг пам’яті (замість створення копії COW )

fork()дзвінки, що мають clone(найменший обмін, )і pthread_create()дзвінки, що надають clone(більшість ). **

forking коштує трохи більше, ніж pthread_createing через копіювання таблиць та створення відображень COW для пам'яті, але розробники ядра Linux намагалися (і досягли успіху) мінімізувати ці витрати.

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

Справді, якщо ви в системі з декількома процесорами, НЕ обмін фактично може бути корисним для виконання: якщо кожна задача виконується на іншому процесорі, синхронізації спільно використовуваної пам'яті є дорогим.

* Спрощена. CLONE_THREADспричиняє поділ сигналів для спільного використання (що потрібно CLONE_SIGHAND, яке розділяє таблицю обробки сигналів).

** Спрощений. Існують SYS_forkі SYS_clonesscall, але в ядрі є sys_forkі sys_cloneобидва дуже тонкі обгортки навколо тієї ж do_forkфункції, яка сама по собі є тонкою обгорткою навколо copy_process. Так, умови process, threadі taskвикористовуються як взаємозамінні , а в ядрі Linux ...

Linux (і справді Unix) дає вам третій варіант.

Варіант 1 - процеси

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

Варіант 2 - нитки

Створіть автономний виконуваний файл, який запускається однією ниткою, і створіть додаткові потоки для виконання деяких завдань

Варіант 3 - виделка

Доступно лише під Linux / Unix, це трохи інакше. Процес роздвоєння насправді є власним процесом із власним адресним простором - нічого, що може зробити дитина (зазвичай), щоб вплинути на адресний простір свого батька чи побратимів (на відміну від потоку) - так ви отримуєте додаткову надійність.

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

Розглянемо програму веб-сервера, яка складається з двох етапів:

1. Прочитайте дані конфігурації та часу виконання
2. Подавайте запити на сторінку

Якщо ви використовували потоки, крок 1 буде виконано один раз, а крок 2 - у кількох потоках. Якщо ви використовували "традиційні" процеси, кроки 1 і 2 потрібно буде повторити для кожного процесу, а пам'ять для зберігання даних конфігурації та часу виконання. Якщо ви використовували fork (), ви можете зробити крок 1 один раз, а потім fork (), залишивши дані часу виконання та конфігурацію в пам’яті, недоторканими, не скопійованими.

Тож дійсно є три варіанти.

Це залежить від безлічі факторів. Процеси мають більшу вагу, ніж потоки, і мають більшу вартість запуску та відключення. Міжпроцесовий зв'язок (IPC) також складніше і повільніше, ніж міжпотокове спілкування.

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

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

Інші обговорили міркування.

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

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

У сучасному Linux (2.6.x) велика різниця у продуктивності між контекстним перемиканням процесу порівняно з потоком (лише потоки MMU є додатковими для потоку). Виникає проблема із спільним адресним простором, а це означає, що несправний вказівник у потоці може пошкодити пам'ять батьківського процесу або інший потік у тому ж адресному просторі.

Процес захищений MMU, тому несправний покажчик просто спричинить сигнал 11 і не пошкодить.

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

Чому, на вашу думку, нитки мають такий великий приріст продуктивності в Linux? Чи є у вас якісь дані для цього чи це просто міф?

Наскільки щільно поєднані ваші завдання?

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

Щоб ще більше ускладнити питання, існує таке поняття, як локальне зберігання потоків і спільна пам'ять Unix.

Місцеве сховище потоків дозволяє кожному потоку мати окремий екземпляр глобальних об'єктів. Єдиний раз, коли я використовував це, коли будував середовище емуляції на Linux / Windows, для коду програми, який працював у RTOS. У RTOS кожне завдання було процесом із власним адресним простором, у середовищі емуляції кожне завдання являло собою потік (із спільним адресним простором). Використовуючи TLS для таких речей, як одиночні, ми мали змогу мати окремий екземпляр для кожного потоку, як і в «реальному» середовищі RTOS.

Спільна пам'ять може (очевидно) принести вам переваги продуктивності наявності декількох процесів доступу до однієї пам’яті, але ціною / ризиком належної синхронізації процесів. Один із способів зробити це - створити один процес створення структури даних у спільній пам’яті, а потім надіслати ручку до цієї структури за допомогою традиційного міжпроцесового зв’язку (як-от названа труба).

У моїй недавній роботі з LINUX одна річ, яку слід пам’ятати - це бібліотеки. Якщо ви використовуєте потоки, переконайтесь, що будь-які бібліотеки, які ви можете використовувати в різних потоках, є безпечними для потоків. Це спалило мене кілька разів. Зокрема, libxml2 не є безпечним для потоків із коробки. Він може бути складений за допомогою безпечного потоку, але це не те, що ви отримуєте при встановленні можливостей.

Я мав би погодитися з тим, що ви чули. Коли ми орієнтуємо наш кластер ( xhplі такий), ми завжди отримуємо значно кращі показники роботи над потоками.</anecdote>

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

На прикладі реального світу веб-сервера apache 1.3 використовувався лише для підтримки декількох процесів, але в 2.0 вони додали абстракцію, щоб ви могли перемикатися між ними. Коментарі, схоже, згодні з тим, що процеси є більш надійними, але потоки можуть дати трохи кращу продуктивність (за винятком Windows, де продуктивність процесів затримується, і ви хочете використовувати лише теми).

У більшості випадків я віддаю перевагу процесам над потоками. потоки можуть бути корисні, коли у вас є відносно менша задача (накладні витрати >>, час зайнятий кожним розділеним блоком завдань) і між ними є необхідність обміну пам'яттю. Подумайте великий масив. Також (offtopic) зауважте, що якщо використання вашого процесора становить 100 відсотків або близьке до нього, від багатопотокового чи оброблення не буде користі. (насправді це погіршиться)

Нитки -> Нитки розділяють простір пам’яті, це абстракція процесора, вона легка. Процеси -> Процеси мають свій простір пам'яті, це абстракція комп’ютера. Щоб паралелізувати завдання, потрібно абстрагувати процесор. Однак переваги використання процесу над потоком - це безпека, стабільність, в той час як потік використовує менше пам'яті, ніж процес, і пропонує меншу затримку. Прикладом з точки зору Інтернету можуть бути хром та фаєрфокс. У разі Chrome кожна вкладка - це новий процес, отже, використання хромової пам'яті вище, ніж Firefox, тоді як забезпечена безпека та стабільність кращі, ніж у Firefox. Безпека, що надається chrome, краща, оскільки кожна вкладка є новою технологією, інша вкладка не може проскочити в пам'ять даного процесу.

Я думаю, що всі зробили чудову роботу, відповідаючи на ваше запитання. Я просто додаю більше інформації про потік проти процесу в Linux, щоб уточнити та узагальнити деякі попередні відповіді в контексті ядра. Отже, моя відповідь стосується конкретного коду ядра в Linux. Згідно з документацією Linux Kernel, немає чіткого розрізнення між потоком та процесом, за винятком того, що потоки використовують спільний віртуальний адресний простір на відміну від процесу. Також зауважте, що ядро ​​Linux використовує термін "завдання" для позначення процесу та потоку в цілому.

"Немає внутрішніх структур, що реалізують процеси або потоки, натомість існує структура task_struct, яка описує абстрактний блок планування, який називається завданням"

Крім того, згідно з Лінусом Торвальдсом, ви НЕ повинні думати про процес проти потоку взагалі, і тому, що це занадто обмежує і єдиною різницею є COE або контекст виконання в термінах "відокремити адресний простір від батьківського" або спільний адресний простір. Насправді він використовує приклад веб-сервера, щоб зробити свою думку тут (що настійно рекомендую прочитати).

Повна кредитна документація на ядро ​​Linux

Якщо вам потрібно поділитися ресурсами, ви дійсно повинні використовувати теми.

Також врахуйте той факт, що контекстні комутатори між потоками значно дешевші, ніж контекстні комутатори між процесами.

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