.Net Как создать пользовательский ThreadPool, общий для всех AppDomain процесса?

Я создал пользовательский ThreadPool, оптимизированный для моих конкретных потребностей. Однако, когда в процессе есть несколько приложений AppDomains, CLR ThreadPool может быть разделен на всех AppDomains, и я хотел бы иметь возможность воспроизвести это поведение..Net Как создать пользовательский ThreadPool, общий для всех AppDomain процесса?

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

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

Так что мои вопросы:

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

источник

2009-11-17 Jeff Cyr

Что побудило решение написать пользовательский поток? Какая функциональность отсутствовала в .NET threadpool? – Walter

CLR ThreadPool не может назначать приоритеты рабочим элементам, стоящим в очереди в пул. Диспетчер CCR предлагает отличные возможности, и я думаю, что интересен гибрид между диспетчером CCR и CLR ThreadPool. –

Подумав об этом, вероятно, это плохая идея попытаться переопределить процесс ThreadPool, CLR ThreadPool уже оптимизирован для этого.

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

источник

2009-11-19 16:31:53

Это звучит практично. Интересно, как вы это делаете, избегая слишком много перераспределения контекста. Мне также нужен пул потоков cross-appdomain, но производительность ключевая. – Wayne

CLR ThreadPool уже является кросс-апдоменом.Если вы хотите создать пользовательский, я думаю, что «самый простой» способ - сделать это в управляемом C++. Но с .Net 4, CLR ThreadPool хорошо оптимизирован, и было бы трудно сделать лучше. Слабость, которую я вижу в CLR ThreadPool, заключается в том, что она не очень изолирована, любая часть кода в процессе, которая немного блокирует поток threadpool, будет зависеть от производительности в реальном времени. Было бы здорово, если бы мы могли создать изолированный экземпляр CLR ThreadPool. –

Кажется, что есть пример Coop Fiber в SDK .Net 2.0, который показывает, как делать то, что вы решите, и позволяет перехватывать все вызовы O/S и любые объекты syncrhonization, которые могут быть заблокированы, чтобы вы могли переключиться на различное волокно. – Wayne

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

В документах MSDN есть пример.

источник

2009-11-19 00:33:33

Пул потоков оптимален, когда имеет один поток на процессор. С вашим решением потоки не распространяются между приложениями. Поэтому, если у вас есть пять рабочих элементов для работы в AppDomain и имеют только 4 ядра процессора, вам нужно 5 потоков, чтобы выполнить все рабочие элементы, это не оптимально. –

Оптимально для чего? Если ваши потоки могут быть привязаны к IO, то один поток за процессор очень субоптимален. Первоначально поток thread framework был установлен на уровне 25/cpu и теперь составляет 250/cpu; никогда 1/cpu. Семафор с использованием Threading.ThreadPool.GetMaxThreads() будет имитировать текущую операцию фреймворка. С удалением, всегда будут собирать накладные расходы, поэтому каждый поток будет иметь более высокую начальную стоимость, чем вы, вероятно, предпочтете. Что касается совместного использования неуправляемого объекта; звучит для меня, как будто вы открываете себе мир боли и ошибок. Я бы этого не сделал. –

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

.Net Как создать пользовательский ThreadPool, общий для всех AppDomain процесса?

ответ

Смежные вопросы