Хотя потоки кажутся небольшим шагом от последовательных вычислений, на самом деле они представляют собой огромный шаг. Они отбрасывают наиболее важные и привлекательные свойства последовательных вычислений: понятность, предсказуемость и детерминизм. Потоки, как модель вычислений, дико недетерминированы, и работа программиста превращается в обрезание этого недетерминизма.
- Проблема с потоками (www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf).
Несмотря на то, что при использовании потоков можно добиться некоторых преимуществ в плане производительности, которые позволяют распределять работу между несколькими ядрами, они часто имеют высокую цену.
Одним из недостатков использования потоков, которые еще не упомянуты здесь, является потеря разделения ресурсов, которые вы получаете с однопоточными пространствами процессов. Например, допустим, вы столкнулись с проблемой сегфоута. В некоторых случаях это можно исправить в многопроцессорном приложении, в котором вы просто позволяете погибающему ребенку умереть и возродите новое. Так обстоит дело в бэкэнде prefork в Apache. Когда один экземпляр httpd выходит из строя, в худшем случае конкретный HTTP-запрос может быть отброшен для этого процесса, но Apache порождает нового потомка и часто этот запрос, если его просто повторно отправить и обслужить. Конечным результатом является то, что Apache в целом не снесен с неисправным потоком.
Другое соображение в этом сценарии - утечки памяти. В некоторых случаях вы можете изящно обработать сбой потока (в UNIX возможно восстановление по некоторым специфическим сигналам - даже segfault / fpviolation -), но даже в этом случае вы могли вытечь всю память, выделенную этому потоку (malloc, new и т. д.). Таким образом, несмотря на то, что процесс может работать, он с течением времени теряет все больше и больше памяти при каждом сбое / восстановлении. Опять же, есть до некоторой степени способы минимизировать это, например использование Apache пулов памяти. Но это по-прежнему не защищает от памяти, которая могла быть выделена сторонними библиотеками, которые, возможно, использовал поток.
И, как отмечают некоторые люди, понимание примитивов синхронизации, пожалуй, самая сложная вещь, чтобы по-настоящему понять все правильно. Эта проблема сама по себе - просто правильная логика для всего вашего кода - может быть огромной головной болью. Таинственные тупики могут возникать в самые странные времена, а иногда даже до тех пор, пока ваша программа не будет запущена в производство, что делает отладку еще более сложной. Добавьте к этому тот факт, что примитивы синхронизации часто сильно различаются в зависимости от платформы (Windows и POSIX), и отладка часто может быть более сложной, а также возможность возникновения условий гонки в любое время (запуск / инициализация, время выполнения и завершение работы), программирование с потоками действительно мало для начинающих. И даже для экспертов, по-прежнему мало пощады только потому, что знание потоков само по себе не уменьшает сложность в целом. Кажется, что каждая строка многопоточного кода экспоненциально усугубляет общую сложность программы, а также увеличивает вероятность появления скрытого тупика или странного состояния гонки в любое время. Также может быть очень сложно написать контрольные примеры, чтобы найти эти вещи.
Вот почему некоторые проекты, такие как Apache и PostgreSQL, большей частью основаны на процессах. PostgreSQL запускает каждый внутренний поток в отдельном процессе. Конечно, это все еще не облегчает проблему синхронизации и условий гонки, но она добавляет немного защиты и в некотором смысле упрощает вещи.
Несколько процессов, каждый из которых выполняет один поток выполнения, могут быть намного лучше, чем несколько потоков, запущенных в одном процессе. А с появлением большей части нового однорангового кода, такого как AMQP (RabbitMQ, Qpid и т. Д.) И ZeroMQ, стало намного проще разделять потоки по разным пространствам процессов и даже машинам и сетям, что значительно упрощает работу. Но все же, это не серебряная пуля. Есть еще сложность для решения. Вы просто перемещаете некоторые свои переменные из пространства процесса в сеть.
Суть в том, что решение войти в область потоков не является легким. Как только вы вступаете на эту территорию, почти мгновенно все становится более сложным, и в вашу жизнь входят новые виды проблем. Это может быть весело и круто, но это похоже на ядерную энергетику - когда дела идут плохо, они могут идти плохо и быстро. Я помню, как много лет назад посещал занятия по критике, и они показали фотографии некоторых ученых в Лос-Аламосе, которые играли с плутонием в лабораториях еще во Второй мировой войне. Многие предпринимали мало или вообще никаких мер предосторожности в случае воздействия, и в мгновение ока - одной яркой, безболезненной вспышкой, все это было бы для них закончено. Дни спустя они были мертвы. Ричард Фейнман позже назвал это « щекоткой хвоста дракона».Это похоже на игру с потоками (по крайней мере, для меня, во всяком случае). Сначала это кажется довольно безобидным, и к тому времени, как ты укусишься, почесал голову, как быстро все пошло плохо. Но, по крайней мере, темы победили. не убью тебя.