Awaiting custom functions

Question

I'm trying to get my head around the new async features in C#, and so far the strangest thing I've noticed is that every example for async features has a function that awaits another async function defined in the framework, but none of them have custom code.

For example, what I want to is create an object from each line in a text file, but asynchronously, so that the UI thread doesn't freeze:

async Task Read()
{
    string[] subjectStrings = File.ReadAllLines(filePath);
    for (int i = 0; i < subjectStrings.Length; i++)
    {
        Task<Subject> function = new Task<Subject>(code => new Subject((string)code), subjectStrings[i]);
        try
        {
            Subject subject = await function;
            subjects.Add(subject);
        }
        catch (Exception ex)
        {
            debugWriter.Write("Error in subject " + subjectStrings[i]);
            continue;
        }
    }
}

As you can see, I define a task that creates a new Subject object based on a line in the text file, and then await this task. If I do this, the debugger gets up to the await line, and then just stops. No more code is run, as far as I know.

If I was using the old async features, I'd just use Task.ContinueWith() and add a callback lambda that adds the subject to the list, and be on my way.

So my questions are:

1. Why does this code not work? How are you supposed to make a custom async method that doesn't use any async methods itself?
2. How are you supposed to use async methods? You can't use await unless you're in an async function, and you're not supposed to call an async method without await, so how do you first call that method from a synchronous method?

Answer 1

You're not starting the task - so it will never finish.

Use Task.Run instead of new Task and it will create and start the task for you.

Note that you're still reading the file synchronously, which isn't ideal... and if your Subject constructor really takes that long to complete, I'd question whether it should be a constructor.

Answer 2

Why does this code not work? How are you supposed to make a custom async method that doesn't use any async methods itself?

Use await Task.Run or await Task.Factory.StartNew to create and run the task. Calling new Task would create a task which isn't started yet. In most cases, this is unnecessary, but you can call Start on tasks created this way.

How are you supposed to use async methods? You can't use await unless you're in an async function, and you're not supposed to call an async method without await, so how do you first call that method from a synchronous method?

Appropriate "root" async call depends on the type of application:

• In console application: Wait on returned Task.

• In GUI application: use async void event handler.

• In ASP.NET MVC: controllers can return Task.

Answer 3

How are you supposed to make a custom async method that doesn't use any async methods itself?

You don't. If the method has no asynchronous work to do, it should be synchronous; it should not be async.

At the core, all async methods come down to one of two approaches. They either queue work to the thread pool via something like Task.Run (not recommended for library code), or they perform true asynchronous work via TaskCompletionSource<T> or a shortcut such as Task.Factory.FromAsync.

How are you supposed to use async methods? You can't use await unless you're in an async function, and you're not supposed to call an async method without await, so how do you first call that method from a synchronous method?

You don't. Ideally, you should be async all the way. Console applications are an exception to this rule; they have to have a synchronous Main. But you should use async all the way for WinForms, WPF, Silverlight, Windows Store, ASP.NET MVC, WebAPI, SignalR, iOS, Android, and Windows Phone applications, as well as unit tests.

You can use async methods via await and combinators such as Task.WhenAll and Task.WhenAny. This is the most common way of using async methods, but not the only one; e.g., you can call an async method and consume it as an IObservable<T>.

Answer 4

You're confusing waiting and working. Waiting uses async/await, working does not. This still means you can await a CPU-bound task, but you have to run it manually, eg.:

var result = await Task.Run(YourLongOperation);

A distinction that helps me understand this on a gut level is, that waiting is cooperative - I voluntarily give up my share of CPU time, because I don't actually need it. Working on the other hand has to run parallel.

In a normal scenario, using only inherently asynchronous async/awaits, there doesn't have to be more than the single thread you started with. It is usually a bad idea to combine CPU-bound operations with I/O-bound ones (CPU-bound will block, unless you explicitly run the task parallely).

Answer 5

I won't bore you with Yet Another Technical Explanation™, instead let me show you a practical example based on your code sample.

Starting with a synchronous version that does all the work on the calling thread.

class SubjectFactory
{
    public IEnumerable<Subject> Read(string filePath)
    {
        string[] subjectStrings = File.ReadAllLines(filePath);

        return Parse(subjectStrings);
    }

    private IEnumerable<Subject> Parse(IEnumerable<string> subjects)
    {
        string code = "XYZ";

        foreach ( var subject in subjects )
        {
            yield return new Subject(code, subject);
        }
    }
}

Assuming that the constructor in Subject is lightweight, the biggest bottleneck is File.ReadAllLines. Why? Because disk I/O is inherently slow.

So how do you go about wrapping that in a task?

If the framework had a File.ReadAllLinesAsync() method, you could await that and be done with it.

public async Task<IEnumerable<Subject>> ReadAsync(string filePath)
{ // Doesn't exist!
    string[] subjectStrings = await File.ReadAllLinesAsync(filePath);

    return this.Parse(subjectStrings);
}

Unfortunately, life is difficult, and so is parallel programming. It's looking like you'll have to reinvent the wheel.

private async Task<string[]> ReadAllLinesAsync(string filePath)
{
    ArrayList allLines = new ArrayList();

    using ( var streamReader = new StreamReader(File.OpenRead(filePath)) )
    {
        string line = await streamReader.ReadLineAsync();

        allLines.Add(line);
    }

    return (string[]) allLines.ToArray(typeof(string));
}

Now you can do the same thing as before, but use your custom method ReadAllLinesAsync().

public async Task<IEnumerable<Subject>> ReadAsync(string filePath)
{
    // call with 'this' instead of 'File'
    string[] subjectStrings = await this.ReadAllLinesAsync(filePath);

    return Parse(subjectStrings);
}

With all that in place, in your WPF app all you got to do is this:

var filePath             = @"X:\subjects\";
var subjectFactory       = new SubjectFactory();
var subjectsCollection   = await subjectFactory.ReadAsync(filePath);
var observableCollection = new ObservableCollection<Subject>(subjectsCollection);