Было бы лучше использовать Task Parallel Library (TPL) в .NET 4.0 .Это даст вам множество полезных функций для абстрагирования от реального процесса создания потоков в пуле потоков.Вы можете использовать шаблон параллельных задач для создания Задачи для каждого из заданий, определенных в XML, и TPL будет обрабатывать планирование этих задач независимо от оборудования.Другими словами, если вы перейдете на компьютер с большим количеством ядер, TPL будет планировать больше потоков.
1) TPL поддерживает понятие задач продолжения .Вы можете использовать их для обеспечения порядка задач и передачи результата одной Задачи или будущего от антецедента к продолжению.Это фьючерсный паттерн .
// The antecedent task. Can also be created with Task.Factory.StartNew.
Task<DayOfWeek> taskA = new Task<DayOfWeek>(() => DateTime.Today.DayOfWeek);
// The continuation. Its delegate takes the antecedent task
// as an argument and can return a different type.
Task<string> continuation = taskA.ContinueWith((antecedent) =>
{
return String.Format("Today is {0}.",
antecedent.Result);
});
// Start the antecedent.
taskA.Start();
// Use the contuation's result.
Console.WriteLine(continuation.Result);
2) Отмена потока поддерживается TPL, но это совместное аннулирование .Другими словами, код, выполняемый в Задаче, должен периодически проверять, отменено ли оно, и корректно ли закрываться.TPL имеет хорошую поддержку для отмены .Обратите внимание, что если вы будете использовать потоки напрямую, вы столкнетесь с теми же ограничениями.Thread.Abort не является жизнеспособным решением почти во всех случаях.
Пока вы это делаете, вы можете захотеть взглянуть на контейнер внедрения зависимостей , такой как Unity, для генерации сконфигурированных объектов из вашего XMLконфигурация.
Ответ на комментарий (ниже)
Джимми: Я не уверен, что понимаю комментарий Холтавольта.Что верно, так это то, что использование параллелизма окупается только в том случае, если объем работы делается значительным, в противном случае ваша программа может потратить больше времени на управление параллелизмом, выполняющим полезную работу.Фактические наборы данных не должны быть большими, но работа должна быть значительной.
Например, если ваши входные данные были большими числами, а вы проверяли, являются ли они простыми, набор данных будет очень маленьким, но параллелизм все равно окупится, потому что вычисления являются дорогостоящими для каждого числа или блока чисел.И наоборот, у вас может быть очень большой набор данных, который вы искали для четности.Это потребовало бы очень большого набора данных, но вычисления все еще очень дешевы, и параллельная реализация могла бы все еще быть не более эффективной.
Канонический пример использует Parallel.For вместо for для перебора набора данных (большого или маленького), но только для выполнения простой числовой операции, такой как сложение.В этом случае ожидаемое улучшение производительности при использовании нескольких ядер перевешивается накладными расходами на создание параллельных задач, планирование и управление ими.