Пул потоков

На днях один хороший знакомый набросал прогу для того, чтобы проверить как работают два потока с одинаковым приоритетом на одно- и многопроцессорных машинах. Сделал он это на C++ (кстати, все помнят что потоки в C++ надо создавать с помощью _beginthread/_beginthreadex, а не с помощью CreateThread). Другой, увидев это дело решил проверить какие особенности планирования потоков для управляемого кода. Ведь CLR-потоки не всегда однозначно соотносятся с потоками ОС. Оказалось что даже для CLR-потоков поведение достаточно ожидаемое (такое же как и для настоящих потоков). Но разговор не про это.

Глянув в код этого товарища я обнаружил примерно следующее:

class test {
void Method1() {
   while (true) {
       Console.WriteLine("x");
   }
}

void Method1() {
   while (true) {
       Console.WriteLine("o");
   }
}

static void Main() {
   Thread t1 = new Thread(new ThreadStart(Method1));
   Thread t2 = new Thread(new ThreadStart(Method2));
   t1.Start();
   t2.Start();
   Console.ReadLine();
}
}

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

class test {
void Method1(object state) {
   char ch = (char)state;
   while (true)
       Console.WriteLine(ch);
}

static void Main() {
   ThreadPool.QueueUserWorkItem(new WaitCallback(Method1), 'x');
   ThreadPool.QueueUserWorkItem(new WaitCallback(Method1), 'o');
   Console.ReadLine();
}
}

Кроме того, что в моем варианте гораздо меньше написано, в нем есть еще одно важное отличие: он не создает новых потоков явно, а просит их у объекта ThreadPool. Давайте разберемся чем это выгодно в реальной задаче. Вводные такие: нам нужно быстренько создать поток и выполнить в нем небольшую задачу (причем, эта задача - не безконечный цикл). Если мы честно напишем

 new Thread(new ThreadStart(Method1))

то система честно создаст для нас новенький, "с иголочки" поток и после того как мы скажем Start() выполнит в нем Method1. Мы все помним, что создание потока - очень дорогостоящая операция! В случае, когда мы просим поток у ThreadPool-а:

 ThreadPool.QueueUserWorkItem(new WaitCallback(Method1), 'x');

нам могут дать не новый поток, а поток который уже кем-то использовался (будем надеятся у него не сильно темное прошлое), а после выполнения нашего Method1 поток не убьют, а приберегут на потом. Вдруг, он еще кому-то понадобиться! В итоге получаеться, что программа может заготовить себе 2-3 потока и использовать их на все случаи жизни. Кроме того, что мы избегаем дополнительных затрат на создание каждый раз нового потока есть еще одна бесплатная вкусность: пока нам этот поток не нужен, его может использовать кто-то другой (например библиотека CLR для выполнения в нем копирования файла). Пожалуй самой яркой аналогией будет мир автомобилей. В наше время почти у каждой семьи в развитых странах есть автомобиль. Это дает возможность быстро домчать куда угодно и не зависеть от общественного транспорта. Но это хорошо лишь до того момента, когда автомобилей становится слишком много (пробки, проблеммы парковки, экология и т.д.). А теперь представьте себе, что каждый вместо того чтобы воспользоваться своим авто - вызывает такси (Вы видели городские улицы в Нью-Йорке?), приежает на работу и такси свободно. Такси едет обслуживать другие вызовы! Общее количество машин уменьшается, улучшается экология, а проблема парковки отпадает вообще.

Вы поняли аналогию с машинами? Ведь, чем меньше в системе потоков, тем быстрее работает система (не тратит время на переключение потоков), тем больше квантов времени достается Вашему потоку.

До появления .NET Framework-а тоже были пулы потоков (читать про CreateIOCompletionPort), но работать с ними было гораздо сложнее. И в маленьких задачах, "игра не стоила свеч". Но теперь работать с ними очень легко, так что - пользуйтесь!