同步到异步的异步工作有奇怪的行为

Question

I have a legacy project with a lot of IoC and HttpClient calls. To improve performance, I'm trying try use TPL to parallelize the work. But the performance became worse.

In summary, we try parallelize a sync method which encapsulates an async method. After refactoring, the performance is better, but I don't understands this behavior.

I made this minimal code example to reproduce the behavior in .NET 4.7 console project:

class Program
{
    static void Main(string[] args)
    {
        var tasks = new List<Task>();
        for (int i = 0; i < 15; i++)
        {
            var n = i;
            tasks.Add(Task.Run(() => WorkSync(n)));
            Thread.Sleep(TimeSpan.FromMilliseconds(1));
        }
        Task.WaitAll(tasks.ToArray());
    }

    private static void WorkSync(int i)
    {
        Debug.WriteLine($"{i:000}\t{DateTime.Now:HH:mm:ss.fff}\tStartA");
        WorkAsync(i).GetAwaiter().GetResult();
        Debug.WriteLine($"{i:000}\t{DateTime.Now:HH:mm:ss.fff}\tFinishA");
    }

    private static async Task WorkAsync(int i)
    {
        Debug.WriteLine($"{i:000}\t{DateTime.Now:HH:mm:ss.fff}\tStartB");
        await Task.Run(() => Work(i));
        Debug.WriteLine($"{i:000}\t{DateTime.Now:HH:mm:ss.fff}\tFinishB");
    }

    private static void Work(int i)
    {
        Debug.WriteLine($"{i:000}\t{DateTime.Now:HH:mm:ss.fff}\tDo Something");
    }
}

Result :

004 11:30:10.629    StartA
000 11:30:10.627    StartA
002 11:30:10.627    StartA
001 11:30:10.627    StartA
003 11:30:10.627    StartA
005 11:30:10.628    StartA
006 11:30:10.628    StartA
007 11:30:10.628    StartA
008 11:30:10.633    StartA
002 11:30:10.692    StartB
001 11:30:10.692    StartB
000 11:30:10.692    StartB
003 11:30:10.692    StartB
005 11:30:10.692    StartB
004 11:30:10.692    StartB
006 11:30:10.695    StartB
007 11:30:10.699    StartB
008 11:30:10.703    StartB
009 11:30:11.632    StartA
009 11:30:11.633    StartB
010 11:30:12.616    StartA
010 11:30:12.617    StartB
011 11:30:13.612    StartA
011 11:30:13.613    StartB
012 11:30:14.612    StartA
012 11:30:14.613    StartB
013 11:30:15.612    StartA
013 11:30:15.613    StartB
014 11:30:16.611    StartA
014 11:30:16.612    StartB
002 11:30:17.612    Do Something
002 11:30:17.614    FinishB
002 11:30:17.615    FinishA
001 11:30:17.615    Do Something
001 11:30:17.657    FinishB
006 11:30:17.658    Do Something
005 11:30:17.636    Do Something
006 11:30:17.680    FinishB
005 11:30:17.701    FinishB
007 11:30:17.723    Do Something
001 11:30:17.658    FinishA
005 11:30:17.744    FinishA
004 11:30:17.744    Do Something
007 11:30:17.765    FinishB
004 11:30:17.808    FinishB
006 11:30:17.723    FinishA
007 11:30:17.830    FinishA
003 11:30:17.894    Do Something
013 11:30:17.786    Do Something
003 11:30:17.895    FinishB
013 11:30:17.917    FinishB
012 11:30:17.919    Do Something
008 11:30:17.830    Do Something
014 11:30:17.788    Do Something
004 11:30:17.851    FinishA
009 11:30:17.851    Do Something
013 11:30:17.922    FinishA
000 11:30:17.872    Do Something
003 11:30:17.918    FinishA
012 11:30:17.927    FinishB
010 11:30:17.922    Do Something
008 11:30:17.931    FinishB
014 11:30:17.933    FinishB
011 11:30:17.955    Do Something
008 11:30:18.046    FinishA
009 11:30:17.958    FinishB
009 11:30:18.111    FinishA
014 11:30:18.068    FinishA
000 11:30:17.980    FinishB
000 11:30:18.114    FinishA
010 11:30:18.024    FinishB
011 11:30:18.089    FinishB
012 11:30:18.003    FinishA
011 11:30:18.138    FinishA
010 11:30:18.116    FinishA

The Work method is executed only after all tasks are started in the Main. I have checked this using the debugger, it isn't the debug display that blocks.

1) I don't understand this scheduling. Can you explain why?

2) The 10 first tasks start very rapidly, but the last 5 tasks start very slowly. Can you explain why?

Answer 1

I don't understand this scheduling. Can you explain why?

You have a tight loop launching a load of tasks. They all start up, but each of them launches another thread. That thread is not being scheduled until after the launching thread calls Debug.WriteLine($"{i:000}\\tFinishB"); .

One reason why the Work() thread is being blocked is that Debug.WriteLine() acquires a lock - so if some other thread is currently writing to Debug the Work() thread will block. The moral of this is that Debug.WriteLine() can change the behaviour of multithreading, because it uses locks.

---

The 10 first tasks start very speed, but the 5 last tasks start very slow. Can you explain why?

However, there is another more impactful reason that this is happening: The "min thread limit" for the threadpool.

The threadpool maintains a minimum number of threads ready waiting to run. You can see that value via the following code:

ThreadPool.GetMinThreads(out int workers, out int ports);
Console.WriteLine(workers);  // Prints 8 on my system.

Now the important thing to know here is that if more than the minimum number of threads are required, new ones will only be created after a delay of a few hundred milliseconds (not sure exactly how long, but it seems to be around one second).

So in addition to the blocking caused by locks in the Debug.WriteLine() implementation, the following is happening:

• A load of tasks are started, consuming more than the minimum threadpool size, so a delay is introduced between new tasks after the first few tasks are started.
• Because of this delay, by the time it comes to the Work() task being started, it's being delayed. This causes it to start much later than it would otherwise.

You can prove that this is happening by increasing the minimum number of threadpool threads at the start of your test code, and observing the difference in output.

To try this, add the following line of code before you launch any tasks:

ThreadPool.SetMinThreads(100, 100);

When I try that, all the tasks start more quickly, and some of the "Do Something" messages appear before all the other tasks are started (whereas previously those messages only appeared AFTER all the other tasks were started, as you noticed).

NOTE Microsoft do not recommended to change the minimum number of threads :

You can use the ThreadPool.SetMinThreads method to increase the minimum number of idle threads. However, unnecessarily increasing these values can cause performance problems. If too many tasks start at the same time, all of them might appear to be slow. In most cases the thread pool will perform better with its own algorithm for allocating threads.