Однопоточное приложение к многопоточному

Question

Когда мы должны использовать потоки в нашем приложении. Другими словами, когда мне следует преобразовать однопоточное приложение в многопоточное. Будучи разработчиком, я считаю задачу, которая мешает вашему приложению работать гладко. Эта задача может быть обработана потоком. Как будто мы постоянно получаем данные GPS. Я думаю, есть другие причины для создания потока в вашем приложении. Пожалуйста, поделитесь своим мнением.

Спасибо.

Answer 1

Причины, которые я могу придумать вне головы (и я уверен, что есть и другие):
1. Выгрузка пакета работы в рабочий поток, чтобы ваша программа могла либо продолжать отвечать на вводимые пользователем данные, либо вы могли продолжить выполнение другого кода, который не полагается на эту работу.
2. Обработка операций ввода-вывода, в частности обмена данными между сервером и сетью, когда время отклика является переменным или неизвестным.
3. Параллельная обработка данных, в которой можно подразделить работу на отдельные независимые единицы работы
4. Работа с таймером, т. Е. «Каждые 500 мс проверяют, изменился ли x»

Однако переключение на многопоточное или параллельное программирование не обходится без ловушек, особенно если этим потокам необходим доступ к общим данным, поэтому возникает количество вопросов по SO о мьютексах и синхронизации потоков !

Answer 2

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

Путем разделения коммуникационного, пользовательского и алгоритмического фрагментов вашего кода (краткий список, особенно если вы выполняете в режиме реального временисистем) в свои собственные потоки, вы повышаете модульность и понятность кода, уменьшаете вероятность появления ошибок из-за непредвиденных последствий и получаете контроль над приоритетом выполнения и синхронизацией.

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

Конечно, многопоточность имеет свои проблемы, особенно условия гонки и события, происходящие из-за ожидаемогопоследовательность, но это можно сделать с помощью семафора, мьютексов и т. п.

Answer 3

Очень хорошая причина для «преобразования» заключается в том, что многоядерные машины становятся нормой, и довольно печально видеть, что старые программы работают плохо, потому что они работают только на одном ядре.

У меня было приложение для обработки чисел, в котором одна часть была очень медленной на Mac с 16 виртуальными ядрами для необходимого (и часто называемого) алгоритма сортировки, который работал только на одном ядре. Я реализовал свой собственный многопоточный алгоритм сортировки, чтобы адаптировать его к числу ядер и бинго, чтобы добиться невероятного ускорения.

Такое очень неоптимизированное поведение хорошо видно при использовании монитора процессора.

Итак, один ответ на ваш вопрос "когда мы должны использовать нить?" просто «когда вы искусственно замедляете работу своего программного обеспечения, заставляя его работать только на одном ядре».

В качестве примечания, это очень интересно, потому что в этом примере сложность алгоритма сортировки остается O (n log n), но «эффект распараллеливания» дает потрясающий прирост скорости.

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

Answer 4

Основное использование многопоточности - это когда требование для параллельных потоков кода.

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

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

Answer 5

Общая идея заключается в том, что вы могли бы получить выгоду от использования нескольких потоков, когда что-то можно сделать параллельно (и у вас есть несколько ядер для использования.) Подумайте о смущающе параллельных задачах Цель здесь - сделать больше работы в одно и то же время. Прочитайте статьи Х. Саттера о Эффективном параллелизме .

Люди часто подключают отзывчивость пользовательского интерфейса к многопоточности. Это не обязательно так и зависит от возможностей конкретной ОС / фреймворка / API, но обычно используется для выполнения длительных операций, таких как открытие / сохранение файла в фоновом потоке, чтобы пользовательский интерфейс не зависал во время этого действия.

Другая ситуация, когда потоки требуются , - это когда вы имеете дело с библиотекой поставщика, которая использует потоки внутри себя (продукты для обмена сообщениями и т. Д.). Здесь у вас нет выбора, но вы имеете дело с потоками явно.

Хотя многопоточность - это не ракетостроение, это сложно. Это окупается большим временем, чтобы получить основы, такие как условия гонки , взаимоблокировки , инверсия приоритета и модели памяти пролив в вашей голове .

Answer 6

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