Какая польза от потоков вне параллельных проблем в многоядерных системах?

Question

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

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

Я могу понять многопоточность, например, MPEG2-декодер, который будет работать на многоядерном процессоре (что я и сделал), но что может оправдать значительные затраты на разработку, связанные с многопоточностью, когда вы говорите об одноядерной системе или даже многоядерная система, если ваша задача не получает значительной производительности от параллельной реализации?

Или, более кратко, какие проблемы, не связанные с производительностью, оправдывают многопоточность?

Редактировать

Ну, я только что наткнулся на один экземпляр, который не ограничен ЦП, но потоки имеют большое значение:

TCP, HTTP и многопоточность Sweet Spot

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

Answer 1

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

Answer 2

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

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

Так что это не просто для многоядерных машин вообще.

Answer 3

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

Answer 4

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

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

Answer 5

какие виды не связанные с производительностью проблемы оправдывают многопоточность?

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

Answer 6

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

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

Answer 7

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

Answer 8

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

1. Длительный запрос отчета пользователем. Когда отчет отправлен, он помещается в очередь для обработки отдельным потоком. Затем пользователь может зайти в приложение и проверить позже, чтобы увидеть состояние своего отчета, у него не осталось страницы или значка «Обрабатывается ...».

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

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

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

Answer 9

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

"Многие люди" ... Кто?

Кроме того, по моему опыту, многие многие программы, которые должны быть многопоточными, отсутствуют (особенно игры. У меня есть i7, и все же большинство игр все еще используют только 1 из моих ядер), поэтому я не уверен, о чем вы говорите. около. Определенно программы типа calc.exe не являются многопоточными (или, если они есть, 1 поток выполняет 99% работы).

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

Да, это правда, но это довольно легко реализовать, и это не то, на что ссылается OP (поскольку в этом случае 1 поток выполняет почти всю работу, и вам нужно всего лишь несколько мьютексов)