Я считаю важным понимать, что такое тредпул. Понимание его внутреннего устройства — его назначения, его философии — позволяет правильнее его использовать. Позволяет лучше понимать, почему с программой происходит то или иное.

Сегодня мы продолжим щупать тредпул. Будем подсовывать ему наши специальные задачи и с помощью них изучать, как он себя ведёт. Как выглядит его работа снаружи. И, надеюсь, это позволит сделать ещё один шаг в сторону понимания его устройства.

На мой взгляд, полезно понимать, как именно наши таски исполняются на тредпуле. В какой момент исполнения тасок под ними могут меняться треды ОС? Какая часть работы в цепочке вызовов асинхронных методов выполняется синхронно, а какая асинхронно? От этих особенностей многое зависит, а от понимания этих нюансов может зависеть эффективность использования этого инструмента. Давайте разбираться.

Важно: мы пока не рассматриваем то, как работает сам тредпул (ну почти), мы рассматриваем то, как работа тасок маппится на потоки приложения.

Экспериментируем

Рассмотрим какой-нибудь типичный случай. Например, http-сервер. Получив http-запрос, сервер запускает таску (Task) по обработке этого запроса. И в процессе исполнения этой таски обычно происходит обработка какой-то цепочки await-вызовов async-методов.

По цепочке асинхронных вызовов методов иногда можно дойти до «по-настоящему» асинхронных вызовов. Например, обращение к БД или к другому микросервису, которое может длиться сколько угодно долго.

Давайте эмулировать такую цепочку асинхронных вызовов. А в качестве «по-настоящему» асинхронного ожидания возьмём просто Task.Delay();. Ну не городить же в тренировочном примере обращение к БД. Уверяю вас, для нашего примера Task.Delay подойдёт также хорошо, как и честный асинхронный сетевой запрос.

Цепочка будет такой: Demonstrate() -> await DoA() -> await DoB() -> await DoC() -> Task.Delay(). До и после каждого await вызова будем писать в лог, в каком потоке мы находимся и какую таску выполняем.

class ThreadPoolChain
{
    private static Random random = new Random();
 
    public static async Task Demonstrate()
    {
        for (var i = 0; i < 10_000; i++)
        {
            Log($"Cycle {i} begins");
            await DoA(i);
            Log($"Cycle {i} ends");
        }
    }
 
    private static async Task DoA(int index)
    {
        LogBegins("A", index);
        await DoB(index);
        LogEnds("A", index);
    }
 
    private static async Task DoB(int index)
    {
        LogBegins("B", index);
        await DoC(index);
        LogEnds("B", index);
    }
 
    private static async Task DoC(int index)
    {
        LogBegins("C", index);
        await Task.Delay(random.Next(1, 300));
        LogEnds("C", index);
    }
 
    private static void LogBegins(string method, int taskIndex)
    {
        Log($"{method} begins: ThreadId = {Thread.CurrentThread.ManagedThreadId}, Task = {taskIndex}");
    }
 
    private static void LogEnds(string method, int taskIndex)
    {
        Log($"{method} ends  : ThreadId = {Thread.CurrentThread.ManagedThreadId}, Task = {taskIndex}");
    }
 
    private static void Log(string s)
    {
        Console.WriteLine(s);
    }
}

Запустим этот код. Давайте внимательно изучим его вывод, я специально раскрасил и выделил цветами интересные закономерности.

Так, синей линией разделяются «индексы» тасок, которые выполняются. То есть это моменты, когда основной цикл запускает в работу новую цепочку вызовов async-методов.

А красными и жёлтыми прямоугольниками я выделил интересные закономерности. Это сплошные промежутки, когда работал один и тот же поток.

Сначала работал поток номер 1, выполняя всю работу таски номер 0, пока не дошел до настоящего асинхронного ожидания (Task.Delay).

Затем, с момента, как Task.Delay завершился, с нашей цепочкой асинхронных вызовов работал поток номер 4. Он выполнял весь код, который после await-вызовов во всех DoA, DoB, DoC. А потом всё он же начал выполнять весь код по новой цепочке вызовов таски с номером 1 в DoA, DoB, DoC. И на Task.Delay он, скорее всего, тоже прервался. Но ему снова «повезло» быть выбранным для работы и повторить этот цикл снова: завершить работу таски номер 1 и начать работу таски номер 2.

Затем работал поток номер 5. Он успел провернуть всего один "цикл": выполнить весь код после Task.Delay у таски номер 2, и выполнить весь код перед Task.Delay у следующей таски номер 3.

И так далее.

Почему иногда одному и тому же потоку достаётся два раза подряд (как например потоку 4) или даже три раза подряд (как например потоку 6) прокрутить эту цепочку асинхронных вызовов? Скорее всего потому, что в приложении больше никакой активности нет, все потоки ничем не заняты, и продолжать выполнять код после Task.Delay() достаётся «любому свободному». А свободные у нас все, вот иногда и достаётся тому же самому.

Можно попробовать изменить эту ситуацию. Запустим в нашем приложении перед нашим Demonstrate паразитную нагрузку на тредпуле, которая будет постоянно что-то делать и мешаться нам:

private static int X;
private static Random random = new Random();
 
static void Main(string[] args)
{
    ThreadPool.SetMinThreads(100, 100);
 
    for (var i = 0; i < 100; i++)
    {
        Task.Run(async () =>
        {
            while (true)
            {
                await Task.Delay(random.Next(0, 5));
                Interlocked.Increment(ref X);
            }
        });
    }
 
    ThreadPoolChain.Demonstrate().GetAwaiter().GetResult();
}

У нас будет крутиться аж 100 тасок, которые иногда просыпаются, чтобы сделать очень короткую работу, и снова засыпают. Важно, что засыпают они асинхронно, не занимая поток: с помощью await Task.Delay().

ThreadPool.SetMinThreads(100, 100) в самом начале мы сделали для того, чтобы заранее "создать" 100 потоков. Детали и нюансы этого вызова мы разберём когда-нибудь позднее, а пока что это важно сделать, чтобы избежать кое-каких сайд-эффектов и они не мешали нам играться.

Давайте посмотрим, как теперь ведёт себя наш эмулятор цепочек вызовов async-методов:

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

Если попытаться раскрасить в подобные цвета код, для наглядности, получится что-то такое:

Начать смотреть такую «раскраску» удобного с метода DoC.

Пусть мы зашли в метод DoC из потока X при работе с задачей под номером i и дошли до Task.Delay. Здесь поток X прекращает работу с задачей i, потому что встречает асинхронное ожидание.

В DoC после асинхронного ожидания мы продолжаем выполнять весь код после Task.Delay уже в каком-то другом потоке Y и выходим из метода всё в том же потоке Y. И это всё ещё при работе с задачей под номером i.

Выйдя из DoC, мы попали во вторую половину метода DoB и продолжили выполнять её в потоке Y, всё ещё работая с задачей под номером i.

Выйдя из DoB, мы попали во вторую половину метода DoA и продолжили выполнять её в потоке Y, всё ещё работая с задачей под номером i.

Выйдя из DoA, мы попали во вторую половину метода Demonstrate и продолжили выполнять её в потоке Y, завершая работу с задачей под номером i. Затем мы начинаем работать с задачей i+1, причем всё ещё в потоке Y, и вызываем DoA.

Войдя в DoA, мы попали в первую половину метода DoA и выполняли её в потоке Y, работая с задачей i+1, пока не зашли в DoB.

Войдя в DoB, мы попали в первую половину метода DoB и выполняли её в потоке Y, работая с задачей i+1, пока не зашли в DoC.

Войдя в DoC, мы попали в первую половину метода DoC и выполняли её в потоке Y, работая с задачей i+1, пока не дошли до Task.Delay, где поток Y прекращает работу с задачей i+1.

Дальше снова, как сначала, только после Task.Delay поток Y сменится на какой-нибудь другой поток W.

Выводы

Какой можно сделать вывод из нашей игрушки?

• Наши асинхронные методы выполняют свою работу в каких-то вполне конкретных потоках.

• Всю цепочку await-вызовов async-методов выполняет один и тот же конкретный поток до тех пор, пока не упрётся в «по-настоящему» асинхронное ожидание. Таковым является, например, Task.Delay(). А вот вызывая метод await httpClient.SendAsync() .NET, на самом деле, выполнит синхронно в этом же потоке ещё тонну кода (внутри http-клиента) перед тем, как упрётся в настоящий асинхронный вызов ожидания ответа от сокета где-то в самых недрах.

• Когда поток добрался до «по-настоящему» асинхронного ожидания, он прекращает работу в этой цепочке await-вызовов async-методов и идёт искать себе новую работу, например работать над ещё одной такой цепочкой.

• Когда «по-настоящему» асинхронное ожидание закончило «ожидать», выбирают первый попавший свободный поток и поручают ему выполнять всю дальнейшую работу после этого await'а до следующего ближайшего «по-настоящему» асинхронного ожидания. (Помните же про автомат?)

• То есть, в теории, во всей цепочке await-вызовов async-методов можно не встретить ни одного «по-настоящему» асинхронного ожидания (например, мы не зайдём в него из-за if'а в самый последний момент) и весь этот код спокойно и совершенно синхронно выполнится в одном и том же потоке, без каких либо прерываний и переключений.