Is it true that async should not be used for high-CPU tasks?

Question

I was wondering whether it\'s true that async-await should not be used for \"high-CPU\" tasks. I saw this claimed in a presentation.

So I guess

Answer 1

There are, in fact, two major uses of async/await. One (and my understanding is that this is one of the primary reasons that it was put into the framework) is to enable the calling thread to do other work while it's waiting for a result. This is mostly for I/O-bound tasks (i.e. tasks where the main "holdup" is some kind of I/O - waiting for a hard drive, server, printer, etc. to respond or complete its task).

As a side note, if you're using async/await in this way, it's important to make sure that you've implemented it in such a way that the calling thread can actually do other work while it's waiting for the result; I've seen plenty of cases where people do stuff like "A waits for B, which waits for C"; this can end up performing no better than if A just called B synchronously and B just called C synchronously (because the calling thread's never allowed to do other work while it's waiting for the results of B and C).

In the case of I/O-bound tasks, there's little point in creating an extra thread just to wait for a result. My usual analogy here is to think of ordering in a restaurant with 10 people in a group. If the first person the waiter asks to order isn't ready yet, the waiter doesn't just wait for him to be ready before he takes anyone else's order, nor does he bring in a second waiter just to wait for the first guy. The best thing to do in this case is to ask the other 9 people in the group for their orders; hopefully, by the time that they've ordered, the first guy will be ready. If not, at least the waiter's still saved some time because he spends less time being idle.

It's also possible to use things like Task.Run to do CPU-bound tasks (and this is the second use for this). To follow our analogy above, this is a case where it would be generally useful to have more waiters - e.g. if there were too many tables for a single waiter to service. Really, all that this actually does "behind the scenes" is use the Thread Pool; it's one of several possible constructs to do CPU-bound work (e.g. just putting it "directly" on the Thread Pool, explicitly creating a new thread, or using a Background Worker) so it's a design question which mechanism you end up using.

One advantage of async/await here is that it can (given the right circumstances) reduce the amount of explicit locking/synchronization logic you have to write manually. Here's a kind of dumb example:

private static async Task SomeCPUBoundTask()
    {
        // Insert actual CPU-bound task here using Task.Run
        await Task.Delay(100);
    }

    public static async Task QueueCPUBoundTasks()
    {
        List tasks = new List();

        // Queue up however many CPU-bound tasks you want
        for (int i = 0; i < 10; i++)
        {
            // We could just call Task.Run(...) directly here
            Task task = SomeCPUBoundTask();

            tasks.Add(task);
        }

        // Wait for all of them to complete
        // Note that I don't have to write any explicit locking logic here,
        // I just tell the framework to wait for all of them to complete
        await Task.WhenAll(tasks);
    }

Obviously, I'm assuming here that the tasks are completely parallelizable. Note, too, that you could have used the Thread Pool yourself here, but that would be a little less convenient because you'd need some way to figure out yourself whether all of them had completed (rather than just letting the framework figure that out for you). You may also have been able to use a Parallel.For loop here.