Тема тредпула, скажем так, complex and hard. У меня в жизни было два «осознания», когда я гордо говорил себе — вот теперь-то я точно понял, как устроен и как работает тредпул в дотнете! Впрочем, после второго раза я неоднократно осознавал, как же я ошибался.

Пользоваться тредпулом просто. И нужно. И современный C# очень хорош, позволяет достаточно эффективно и просто им пользоваться, иногда даже не осознавая почти ничего о его устройстве. А современный .Net очень хорошо реализует тредпул (особенно, в сравнении с .NetFramework).

Чтобы пользоваться тредпулом искусно, недостаточно «понимать» его устройство. Тредпул надо чувствовать, ощущать. И, безусловно, читать его код. Кстати, мало кто знает, но в Контуре когда-то очень давно даже была своя реализация тредпула! Я же постараюсь подходить к этой теме издалека, разбирая разные забавные ситуации. И, надеюсь, в рамках этих статей удастся когда-нибудь погрузиться и в самые недра.

Let's play

А сейчас, давайте поиграемся с Task'ами. Думаю, в нашем обществе смело можно опустить вводную, что Task'и непосредственно связаны с тредпулом. А также то, что в тредпуле есть набор WorkerThread'ов и CompletionPortThread'ов, которые и будут исполнять наши задачи.

Давайте напишем код, который будет запускать таску с весьма простой работой внутри — сложением чисел. Дожидаться её исполнения. И затем запускать следующую точно такую же таску.

public static int X;
 
public static void RunOneTaskSequentially()
{
    while (true)
    {
        Task.Run(() => X += 1).GetAwaiter().GetResult();
    }
}

Запустим?

Ой! Этот код на 4х ядерной машине потребляет почти все 4 ядра (91%). Хотя код выглядит абсолютно точно «однопоточным». Сколько же потоков съел этот процесс?

Потоков тут 17. Немножко неожиданно от программы, которая «должна» работать в один поток. Ну как должна. Это мы такого хотели, интуитивно пользуясь тредпулом. А активно и примерно равномерно потребляют CPU аж целых 10 потоков.

Чем же заняты треды? Заглянем в один из них.

Чем-то непонятным. Все треды (где потрачено много циклов CPU) заняты работой в практически идентичных стеках. Давайте трейс снимем.

Те две строчки по 15% — это методы из Main-треда. Которые стартуют, и дожидаются завершения работы таски. Они нам не интересны. А чем занята та непонятная функция из ntdll, которая потребила 62% от времени работы программы (от всех тредов)?

А это просто CPU работа где-то в тредах. В разных тредах. CPU-работа в недрах дотнета.

Давайте заглянем чуть глубже. Благо, у нас Windows. Снимем трейс с нашего горе-приложения с помощью WPR, откроем в WPA. Изучим, что за функции самые популярные.

Что мы тут видим? Огромное количество работы, связанной с тредпулом. Это свопы контекста, разные функции с подстрокой «Thread». А также мы видим CLRLifoSemaphore::Wait — это «спящие» треды тредпула. А вот ThreadNative::SpinWait — откровенная CPU-работа. И её доля очень высока. Если что, всякие Rtlp* функции — это функции сбора той телеметрии, что мы сейчас смотрим. Их надо игнорировать.

«Скроем» откровенные бесполезные ожидания, потому что они не тратят на самом деле CPU (что не совсем правда, но всё равно). Скроем Rtlp* методы, потому что они не про полезную работу. Убедимся, что большую часть времени занимают всё ещё всякие «бесполезные» функции:

Ещё можно посмотреть статистику не в разрезе функций, а в разрезе стеков. Но там ничего интересного, мы увидим все те же функции, но сгруппированные по стекам. И там всё также преобладает всякая тредпульная обёртка.

Что мы увидели?

Итого, какой вывод мы можем сделать. В нашем коде работа самого тредпула существенно преобладает над полезной работой. Работа по постановке новых тасок, работа с очередью задач, выбор и активация WorkerThread'а для исполнения нашего сложения, контекст-свичи, ожидания (а особенно SpinWait'ы). И эта работа (где-то не вся, а лишь частично), безусловно, выполняется во всех тредах тредпула. А значит параллельно.

Мы «разворошили» тредпул своей агрессивной постановкой и завершением тасок. Все воркер-треды переполошились и старательно пытались быть полезными в обработке нашей малюсенькой задачи. И в итоге, они все (WorkerThread'ы) поделали кучу работы, чтобы один из них сложил чиселко. И так while true.

Успокоим бедняжку-тредпул

Что будет, если удлинить операцию? В одной «таске» делать побольше «полезной» работы подряд? Чтобы было меньше лишних телодвижений, больше полезной работы.

static int OperationsCount;
static int ActionsInOperation;
 
public static void RunOneTaskSequentially()
{
    for (var i = 0; i < OperationsCount; i++)
    {
        Task.Run(() => ChangeFunction()).GetAwaiter().GetResult();
    }
}
 
private static Action ChangeFunction = () =>
{
    for (int i = 0; i < ActionsInOperation; i++)
        Interlocked.Increment(ref X);
};

Замерим время выполнения нашей RunOneTaskSequentially с разными параметрами.

Запустим наш код с разными аргументами: OperationsCount и ActionsInOperation:

Elapsed 00:00:09.5915062. OperationsCount = 10000000, ActionsInOperation = 1.
Elapsed 00:00:01.1307198. OperationsCount = 1000000, ActionsInOperation = 10.
Elapsed 00:00:00.1640366. OperationsCount = 100000, ActionsInOperation = 100.
Elapsed 00:00:00.0795597. OperationsCount = 10000, ActionsInOperation = 1000.

Зависимость тривиально прослеживается. Легко заметить, что чем длиннее работа внутри таски, и чем меньше телодвижений в тредпуле, тем эффективнее наша программа. А результат одинаковый (X в конце везде равен 10000000). На одинаковое количество «полезной» работы мы делаем меньше «бесполезной» работы тредпула.

Мораль

Тредпул и его работа совершенно не бесплатна. Тредпул — очень (относительно) дорогая и сложная штука. И его ресурсами нужно пользоваться аккуратно. Пока что я хотел продемонстрировать именно это.

Прямо сейчас не получится сформулировать какие-то best-practices, или же наоборот. Но какое-то наблюдение зафиксировать можно:

• Не выполняйте на тредпуле очень короткие и небольшие CPU-задачи, если они не связаны ни с какой IO-работой.

Кстати, выполнять на тредпуле очень длинные, долгие CPU-задачи тоже ни в коем случае нельзя. Если что, тредпул вообще не предназначен для выполнения CPU-bound работ. Тредпул нужен только для эффективного связывания различной «вспомогательной» и небольшой работы с асинхронной, IO-работой. Если вам нужно жечь CPU полезной работой, для этого есть инструменты намного лучше. Почему — это мы обязательно рассмотрим позднее.