Вопрос по .net, threadpool, appdomain – .Net Как создать собственный поток ThreadPool, общий для всех доменов приложения процесса?

4

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

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

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

Итак, мои вопросы:

Есть ли способ создать пользовательский пул потоков, используя удаленное взаимодействие с минимальными издержками?Если нет, возможно ли разделить неуправляемый объект через AppDomain?
CLR ThreadPool может '• расставить приоритеты рабочих элементов, поставленных в очередь в пул. Диспетчер CCR предлагает большие возможности, и я думаю, что гибрид между диспетчером CCR и CLR ThreadPool был бы интересен. Jeff Cyr
Что побудило принять решение написать собственный пул потоков? Какая функциональность отсутствовала в пуле потоков .NET? Walter

Ваш Ответ

2   ответа
2

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

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

Оптимально для чего? Если ваши потоки могут быть связаны с вводом-выводом, то процесс «один поток на процессор» крайне неоптимален. Рамкипул потоков изначально был увеличен до 25 / процессор, а теперь 250 / процессор; никогда 1 / процессор. Семафор, использующий Threading.ThreadPool.GetMaxThreads (), будет имитировать фреймворк.текущая операция. С удалениемэто всегда будет излишними издержками, поэтому каждый поток будет иметь более высокую стоимость запуска, чем вы.Я бы предпочел. Что касается совместного использования неуправляемого объекта; звучит для меня как тыВы открываете себе мир боли и ошибок. Я бы нене делай этого. Steve Cooper
Вы правы, что я должен был указать оптимальные значения для обработки, связанной с процессором. Однако даже для обработки, связанной с вводом-выводом, блокировка потока пула потоков с помощью операции ввода-вывода редко является хорошей идеей, вместо этого следует использовать порт завершения ввода-вывода. Jeff Cyr
Пул потоков является оптимальным, если он имеет один поток на процессор. С вашим решением потоки не распределяются между доменом приложения. Таким образом, если у вас есть пять рабочих элементов в очереди приложений AppDomain и только 4 ядра процессора, вам нужно 5 потоков для выполнения всех рабочих элементов, это не оптимально. Jeff Cyr
0

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

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

Это звучит практично. Интересно, как вы это делаете, избегая слишком частого переключения контекста. Мне также нужен пул потоков между приложениями, но производительность является ключевым фактором. Wayne
Кажется, что в .Net 2.0 SDK есть пример Coop Fiber, который показывает, как делать именно то, что вы решаете, и позволяет перехватывать все вызовы к O / S и любые объекты синхронизации, которые могут быть заблокированы, чтобы вы могли переключиться на другой Fiber. Wayne
CLR ThreadPool уже является кросс-доменом приложения. Если вы хотите сделать заказной, я думаю, что "Самый простой» способ сделать это в управляемом C ++. Но начиная с .Net 4, CLR ThreadPool хорошо оптимизирован, и было бы трудно добиться большего. Слабость, которую я вижу с CLR ThreadPool, заключается в том, что он недостаточно хорошо изолирован, любой фрагмент кода в процессе, который слегка блокирует пул потоков 'S поток будет винт любой производительности в режиме реального времени. Было бы здорово, если бы мы могли создать изолированный экземпляр CLR ThreadPool. Jeff Cyr
Поцарапайте мой последний комментарий. Похоже, они удалены. Плюс, Дух! Я'm, использующий 3.5 из SDK ... 2.0 слишком стар, чтобы играть с ним сейчас. 3,5 и 4,0 неt поддержка, кажется, планирование режима пользователя. Wayne

Похожие вопросы