Хоча нитки здаються невеликим кроком від послідовного обчислення, насправді вони представляють собою величезний крок. Вони відкидають найважливіші та привабливі властивості послідовних обчислень: зрозумілість, передбачуваність та детермінізм. Нитки, як модель обчислення, дико недетерміновані, і робота програміста стає однією з обрізань цього недетермінізму.
- Проблема з нитками (www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf).
Хоча є деякі переваги в роботі, які можуть бути використані, використовуючи нитки, в яких ви можете розподілити роботу по декількох ядрах, вони часто отримують велику ціну.
Один з недоліків використання потоків, про які ще не було сказано, - це втрата розділення ресурсів, яку ви отримуєте за допомогою єдиних потокових процесорів. Наприклад, скажімо, ви натрапили на випадок segfault. У деяких випадках можна відновлюватись цим у багатопроцесорному застосуванні, якщо ви просто дозволите дитині, яка винила, померти та відновити нову. Це стосується попереднього форкенду Apache. Коли один екземпляр httpd йде вниз, гіршим випадком є те, що конкретний запит HTTP може бути відхилений для цього процесу, але Apache породить нову дитину і часто запит, якщо його просто обурюють і обслуговують. Кінцевий результат полягає в тому, що Apache в цілому не знімається з несправної нитки.
Іншим врахуванням у цьому сценарії є витоки пам'яті. Є деякі випадки, коли ви можете вишукано обробити обрив потоку (в UNIX можливе відновлення деяких специфічних сигналів - навіть segfault / fpviolation), але навіть у цьому випадку ви, можливо, просочили всю пам'ять, виділену цим потоком (malloc, new тощо). Тож, хоча ваш процес може жити далі, з часом витікає все більше пам’яті з кожною помилкою / відновленням. Знову ж таки, є певною мірою способи мінімізувати подібне використання Apache пулів пам'яті. Але це все ще не захищає від пам’яті, яку, можливо, виділили сторонні лібри, якими могла користуватися нитка.
І, як дехто зазначав, розуміння примітивів для синхронізації - це, мабуть, найскладніше, що дійсно виходить правильно. Ця проблема сама по собі - просто отримання загальної логіки для всього вашого коду - може стати величезним головним болем. Таємничі тупики, як правило, трапляються в найдивніші часи, а іноді навіть до тих пір, поки ваша програма не запущена у виробництво, що ускладнює налагодження все складніше. Додайте до цього той факт, що примітиви синхронізації часто сильно відрізняються від платформи (Windows проти POSIX), а налагодження часто може бути складніше, а також можливість перегонових умов у будь-який час (запуск / ініціалізація, час виконання та вимкнення), програмування з нитками дійсно мало пощади для початківців. І навіть для експертів, все ще мало милосердя лише тому, що знання самої нитки не зводить до мінімуму складність взагалі. Кожен рядок потокового коду іноді, здається, експоненціально ускладнює загальну складність програми, а також збільшує ймовірність появи прихованого глухого кута або дивного стану гонки на будь-який час. Також може бути дуже важко написати тестові випадки, щоб розірвати ці речі.
Ось чому деякі проекти, такі як Apache та PostgreSQL, здебільшого базуються на процесах. PostgreSQL запускає кожен потік потоку в окремому процесі. Звичайно, це все ще не полегшує проблеми синхронізації та умов перегонів, але це додає досить небагато захисту та певним чином спрощує справи.
Кілька процесів, кожен з яких виконує один потік виконання, можуть бути значно кращими, ніж кілька потоків, що працюють в одному процесі. І з появою більшої частини нового однорангового коду, як AMQP (RabbitMQ, Qpid та ін.) Та ZeroMQ, набагато простіше розділити потоки по різних технологічних просторах і навіть машинах та мережах, значно спрощуючи речі. Але все-таки це не срібна куля. Складно вирішити проблеми. Ви просто переміщаєте деякі змінні з процесного простору в мережу.
Суть полягає в тому, що рішення про введення в область ниток не є легким. Як тільки ви ступаєте на цю територію, майже миттєво все стає складнішим, і у ваше життя вступають цілі нові породи проблем. Це може бути весело і круто, але це як атомна енергетика - коли справи йдуть не так, вони можуть йти погано і швидко. Я пам’ятаю, як багато років тому проходили заняття з критичної критики, і вони показали фотографії деяких вчених з Лос-Аламосу, які грали з плутонієм у лабораторіях ще у часи Другої світової війни. Багато хто вживав мало заходів щодо запобігання події, якщо їх не було, і за мить ока - одним яскравим, безболісним спалахом, для них все закінчиться. Через кілька днів вони були мертві. Пізніше Річард Фейнман назвав це " лоскотом дракона за хвіст"Це те, як може виглядати гра з нитками (принаймні, для мене в будь-якому випадку). Спочатку це здається досить нешкідливим, а до моменту, коли ви покусали, чухаєте голову про те, як швидко погіршилися речі. Але принаймні нитки виграли я тебе не вб'ю.