Самый быстрый способ асинхронного выполнения метода?

Question

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

В настоящее время я застрял с

ThreadPool.UnsafeQueueUserWorkItem

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

Answer 1

Команда CLR (4) рекомендует:

Задача теперь является предпочтительным способом поставить работу в очередь в пул потоков.

Читать CLR 4.0 Улучшения ThreadPool: часть 1 и Новый и улучшенный CLR 4 Engine Thread Pool * для получения подробной информации. Одним словом, причины: локальные очереди, повторное использование потоков, кража работы . В основном для балансировки нагрузки.

Дополнительно:

Я не понимаю, почему это не ответ (пониженный голос).

Вы написали

Мне нужно отправить множество функций в другой поток, чтобы предотвратить блокировку текущей функции "

Я отвечаю: Некоторые «блоки» TPL (существуют для net35) ( одновременных коллекций, вращающихся примитивов и т. Д.) Разработаны специально для высококонкурентного доступа, при этом фокусируется на минимизации или устранении блокировок для эффективного управления Работа. Вы также можете использовать эти блоки (например, BlockingCollection для вашей задачи). TPL предназначен для создания и обработки сотен (или даже тысяч) связанных с процессором / io операций (задач) с минимальными издержками (или миллионами с помощью PLinq).

Вы спросили:

Мне просто интересно, что лучше для такой задачи?

Я уже ответил: лучшая практика - TPL (обосновано, а не только моя рекомендация)

Answer 2

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

Отредактировано после прочтения одного из ваших комментариев:

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

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

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

Answer 3

Может быть, вы могли бы выбросить все свои запросы на отправку в список <> и запустить другой фоновый поток для выполнения вызовов QueueUserWorkItem.

Правильно ли я понимаю проблему?