ThreadPool вызывает зависание графического интерфейса (?)

Question

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

Кто-нибудь может объяснить это явление?

Answer 1

Ух ты! Не связывайтесь с подсчетом ThreadPool, если вы не знаете, что делаете - многие важные службы .NET могут использовать его и полагаться на то, что он не насыщен. Вы почти наверняка заблокировали основной код ввода-вывода через насыщение.

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

У Джо Даффи (который знает больше о потоках, чем я когда-либо узнаю) есть некоторые соображения по этому поводу. 667dbd7d2108.aspx "rel =" nofollow noreferrer "> здесь .

Re, как заблокировать это через насыщение - это просто воспроизвести в мысленном эксперименте; Предположим, у вас есть немного рабочего кода, который должен сделать 2 вещи ... мы поместим 1 из них в ThreadPool и сделаем один самостоятельно; выполнив нашу собственную работу, мы присоединимся к () [или эквиваленту ThreadPool] второй задачи, чтобы мы знали, что обе задачи выполнены.

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

Вы можете сделать то же самое с портами завершения ввода / вывода.