More async and task questions

So, if I have an async method FooAsync() that returns Task<T> does that mean that all functions/methods that call my FooAsync() will need to be an async method as well?

Ideally, yes. The main benefit of async is that it doesn't have to block a thread while waiting for something, if you wait on a task synchronously this benefit is largely lost. There is also a risk of deadlocks if your async method doesn't use ConfigureAwait(false).

Asynch Programming Model

There is a helper method for this purpose.

The docs look like a mess because it needs fairly flexible overloads, but you can look at some usage examples.

Third, If I want a background thread that checks status and performs it's own utility process continuously alongside my main app would I use Task.Run()

The reason why Task.Run is discouraged for long running operations is because it uses the thread pool, which expects to get its thread back reasonably quickly and will hesitate to start new threads leading to potential scaling/performance problems. In practice, doing it once probably won't have any noticeable effect, though.

If you want to reap the benefits of async code, you need async all the way to the top. C# 7.1 allows an async main, so there's no reason not to. Of course, if you're doing a GUI desktop app there's a lot of care to be taken around thread contexts, but that's a separate issue.

​

It's fairly easy to wrap old callback-based async code. What you'll want to look at is the TaskCompletionSource.

​

Whether you run the task from it's own class or not, does not matter a lot, I think (I personally prefer to push status updates from the worker process). If it's going to be long-lived, make sure to use the appropriate flags. Consult David Fowlers excellent list to make sure you aren't falling into any less-than-obvious traps.

The async keyword tells the compiler you plan to use the await keyword somewhere in the method. If you don't use await I think it's a compiler warning. You can call a method marked async without using await; if you do, it returns a Task or Task<T> and you're expected to do something with that.

So in summary: you only need to add async if you use await.

Second question:

There are idioms and patterns for converting older async patterns to the Task pattern. But await only works with async methods. So in general you have to make a new class that hides the old async pattern behind a method that returns a Task<T>.

Third question:

Don't use tasks or thread pool threads for long-running things. Use Thread. Tasks are expected to complete.

Personally: I don't use await which means I never have to worry about async. Or a lot of other baggage you can read in thousands of articles about how the most intuitive ways to use async and await can hinder performance, cause deadlocks, and lead to unobservable exceptions.