Когда многопоточность не является хорошей идеей? [закрытый]

Перефразировать старую кавычку: у программиста была проблема. Он думал, "Я знаю, я буду использовать потоки". Теперь у программиста есть две проблемы. (Часто приписываемый JWZ, но это, кажется, предшествует его использованию его говорящий о regexes.)

А хорошее эмпирическое правило, "Не используют потоки, если нет очень неопровержимый довод для использования потоков". Несколько потоков напрашиваются на неприятности. Попытайтесь найти хороший способ решить проблему, не используя несколько потоков, и только отступить к использованию потоков при предотвращении, чтобы это было столько же проблемы сколько дополнительное усилие использовать потоки. Кроме того, рассмотрите переключение на несколько потоков, если Вы работаете на многоядерной машине / машине мульти-ЦП, и тестирование производительности единственной потоковой версии показывает что Вы потребность производительность дополнительных ядер.

Многопоточность является плохой идеей если:

• Несколько доступов потоков и обновления тот же ресурс (устанавливает переменную, пишут в файл), и Вы не понимаете потокобезопасность .

• Несколько потоков взаимодействуют друг с другом, и Вы не понимаете взаимные исключения и подобные инструменты управления потоком.

• Ваша программа использует статические переменные (потоки обычно совместно используют их по умолчанию).

• Вы не отладили проблемы параллелизма.

На самом деле много поточная обработка не масштабируема и трудна отладить, таким образом, она не должна использоваться в любом случае, если можно избежать его. Существует немного случаев, где это обязательно: когда производительность на много ЦП имеет значение, или когда Вы имеете дело с сервером, которые имеют много клиентов, требующихся много времени для ответа.

В любых других случаях, можно использовать альтернативы, такие как очередь + задания крона или иначе.

Вы могли бы хотеть смотреть на Dan Kegel" проблема C10K " веб-страница об обработке нескольких источников/приемников данных.

В основном лучше использовать минимальные потоки, которые в сокетах могут быть сделаны в w/большей части ОС некоторая система событий (или асинхронно в Windows с помощью IOCP).

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

схема В качестве примера расположения:

Per CPU [*] EVENTLOOP   ------ Handles nonblocking I/O using OS/library utilities
                       |                        \___  Threadpool for various blocking events
                       Threadpool for handling the I/O messages that would take long

Многопоточность не является хорошей идеей, если необходимо гарантировать точную физическую синхронизацию (как в примере). Другие недостатки включают интенсивный обмен данными между потоками. Я сказал бы, что многопоточность хороша для действительно параллельных задач, если Вы не заботитесь очень об их относительной скорости/priority/timing.

Недавнее приложение я записал, что имел для использования многопоточности (хотя не неограниченное количество потоков) был тот, куда я должен был передать в нескольких направлениях более чем два протокола плюс контроль третьего ресурса для изменений. И библиотеки протокола потребовали, чтобы поток выполнил соответствующий цикл событий в, и когда те составлялись, было легко создать третий цикл для контроля ресурса. В дополнение к требованиям цикла событий сообщения, проходящие провода, имели строгие требования синхронизации, и одним циклом нельзя было рискнуть, блокируя другой, что-то, что было далее облегчено при помощи многоядерного ЦП (SPARC).

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

, В целом, потоки должны, если это возможно, только быть рассмотренными, когда можно разделить работу в четко определенные задания (или серия заданий) таким образом, что семантика относительно легка к документу и реализации, и можно поместить верхнюю границу на количество потоков, которые Вы используете и которые должны взаимодействовать. Системы, где это лучше всего применяется, являются почти системами передачи сообщений.

В priciple каждый раз нет никаких издержек для вызывающей стороны для ожидания в очереди.

Пара более возможных причин для использования потоков:

1. Ваша платформа испытывает недостаток в асинхронных операциях ввода-вывода, например, Windows Me (Никакие порты завершения или перекрытый ввод-вывод, боль при портировании приложений XP, которые используют их.) Java 1.3 и ранее.
2. сторонняя библиотечная функция А, которая может зависнуть, например, если удаленный сервер снижается, и библиотека не обеспечивает способа отменить операцию, и Вы не можете изменить его.

Хранение GUI, быстро реагирующего во время интенсивной обработки, не всегда требует дополнительных потоков. Отдельная функция обратного вызова обычно достаточна.

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

Я сказал бы, что многопоточность обычно привыкла к:

1. Позволяют обработку данных в фоновом режиме, в то время как GUI остается быстро реагирующим
2. анализ очень больших данных Разделения на несколько блоков обработки так, чтобы можно было получить более быстрые результаты.
3. , Когда Вы получаете данные из некоторых аппаратных средств и нуждаетесь в чем-то для непрерывного добавления его к буферу, в то время как некоторый другой элемент решает, что сделать с ним (пишут в диск, дисплей на GUI и т.д.).

Поэтому, если Вы не решаете одну из тех проблем, маловероятно, что добавление потоков сделает Вашу жизнь легче. На самом деле это почти наверняка сделает его тяжелее, потому что, поскольку другие упомянули; отладка mutithreaded приложения является значительно большим количеством работы, чем единственное потоковое решение.

безопасность могла бы быть причиной избегать использования нескольких потоков (по нескольким процессам). См. Google Chrome для примера функций безопасности мультипроцесса.

Процессы параллельны? Действительно ли производительность является реальным беспокойством? Есть ли несколько 'потоков' выполнения как на веб-сервере? Я не думаю, что существует конечный ответ.

Multithreading is bad except in the single case where it is good. This case is

1. The work is CPU Bound, or parts of it is CPU Bound
2. The work is parallelisable.

If either or both of these conditions are missing, multithreading is not going to be a winning strategy.

If the work is not CPU bound, then you are waiting not on threads to finish work, but rather for some external event, such as network activity, for the process to complete its work. Using threads, there is the additional cost of context switches between threads, The cost of synchronization (mutexes, etc), and the irregularity of thread preemption. The alternative in most common use is asynchronous IO, in which a single thread listens to several io ports, and acts on whichever happens to be ready now, one at a time. If by some chance these slow channels all happen to become ready at the same time, It might seem like you will experience a slow-down, but in practice this is rarely true. The cost of handling each port individually is often comparable or better than the cost of synchronizing state on multiple threads as each channel is emptied.

Many tasks may be compute bound, but still not practical to use a multithreaded approach because the process must synchronise on the entire state. Such a program cannot benefit from multithreading because no work can be performed concurrently. Fortunately, most programs that require enormous amounts of CPU can be parallelized to some level.

Распространенным источником проблем с потоками являются обычные подходы, используемые для синхронизации данных. Совместное использование потоков потоками с последующей реализацией блокировки во всех соответствующих местах является основным источником сложности как для проектирования, так и для отладки. Правильная блокировка для баланса стабильности, производительности и масштабируемости - всегда сложная проблема. Даже самые опытные специалисты часто ошибаются. Альтернативные методы работы с потоками могут значительно облегчить эту сложность. В языке программирования Clojure реализовано несколько интересных методов работы с параллелизмом.

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

Когда вам не следует использовать многопоточность, это вводит в заблуждение вопрос к вашей проблеме. Ваша проблема заключается в следующем: почему многопоточность моего приложения привела к сбою последовательной / локальной сети?

Ответ на этот вопрос будет зависеть от реализации, что следует обсудить в другом вопросе. Я точно знаю, что в многопоточном приложении может происходить и Ethernet, и последовательная связь одновременно с множеством других задач, не вызывая потери данных.

Единственная причина не использовать многопоточность:

1. Есть одна задача и нет пользовательского интерфейса, с которым задача будет мешать.

Причины использования многопоточности:

1. Обеспечивает превосходную скорость реакции для пользователя
2. Выполняет несколько задач одновременно, чтобы уменьшить общее время выполнения
3. Использует больше современных многоядерных процессоров и многоядерных процессоров будущего.

Существует три основных метода многопоточного программирования, которые позволяют легко реализовать безопасность потоков - вы только необходимо использовать один для успеха:

1. Thread Safe Типы данных, передаваемые между потоками.
2. Потоковые методы в многопоточном объекте для изменения данных, передаваемых между ними.
3. Возможности PostMessage для связи между потоками.