Темы или асинхронность?

Question

Как вы делаете ваше приложение многопоточным? Вы используете асинхронные функции? или вы создаете новую тему? Я думаю, что асинхронные функции уже порождают поток, поэтому, если ваша работа просто читает файлы, лениться и просто порождать вашу работу в потоке, это просто «тратит» ресурсы ... Так есть ли какой-то дизайн при использовании потоковых или асинхронных функций?

Answer 1

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

PS: и следите за Parallel Extensions от Microsoft

Answer 2

Создание потоков приводит к потере ресурсов только в том случае, если вы начнете создавать их тонны, один или два дополнительных потока не повлияют на производительность платформы, в Infact System в настоящее время для меня более 70 потоков, а msn использует 32 ( Я действительно понятия не имею, как мессенджер может использовать такое количество потоков, особенно когда он свернут и ничего не делает ...)

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

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

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

Иногда вы можете разбить ваше приложение на пару отдельных частей, которые работают в своих собственных потоках. Например, в играх обновления / физика и т. Д. Могут быть одним потоком, а графические объекты - другим, звук / музыка - третьим, а сетевое взаимодействие - другим. Проблема здесь в том, что вам действительно нужно подумать о том, как эти части будут взаимодействовать, иначе у вас может быть плохая производительность, ошибки, которые кажутся «случайными», или это может даже привести к тупику.

Answer 3

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

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

Как однопоточное приложение, оно, как и следовало ожидать, занимало время, составляя в среднем около 1 URL в секунду для страницы размером 50 КБ. Не так уж плохо, но когда вы масштабируете необходимость обрабатывать тысячи URL-адресов в пакете, это бесполезно.

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

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

Answer 4

Ответ "это зависит".

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

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

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

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

Следующее решение заключается в использовании асинхронного ввода-вывода. Обычно рекомендуется только для людей, пишущих некоторые из очень сильно загруженных серверов, и даже тогда я предпочел бы повторно использовать одну из существующих платформ, которые абстрагируют детали, например. каркас C ++ ICE или EJB-сервер под Java.

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

Answer 5

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