Question

OK first of all, it’s nothing that I need to implement or anything. I just need to know the answer because someone more experienced told me that asynchronous execution doesn’t necessarily have to involve a new thread as threads are somewhat heavy constructs, which confused me a lot and I couldn’t agree.

Now let’s say, I have two methods – Execute() and ExecuteAsync(). Execute() is running on the main thread. I want to call ExecuteAsync() from within Execute() and I don’t care whenever it completes executing, but when it does, may be (or may be not) I want use it’s return value. That’s a typical example of an asynchronous execution, right?

I know I can do this using BackgroundWorker or IAsyncResult (Delegate.BeginInvoke()), but AFAIK under the hood they spawns a secondary CLR Thread/ThreadPool Thread.

So is it anyhow possible to execute the method ExecuteAsync() asynchronously without the help of a second thread?

EDIT : I think this edit will clarify the scenario further. Invoking ExecuteAsync() is NOT the only (or last) task for Execute() to perform. Execute() should continue it’s own tasks without caring about the execution of ExecuteAsync() method.

Answer 1

Here is an example of a program that uses asynchrony and never ever uses more than one thread:

public class Foo
{
    private int _value;
    private TaskCompletionSource<bool> tcs = new TaskCompletionSource<bool>();
    public int Value
    {
        get
        {
            return _value;
        }
        set
        {
            _value = value;
            var oldTCS = tcs;
            tcs = new TaskCompletionSource<bool>();
            oldTCS.SetResult(true);
        }
    }


    public Task ValueChanged()
    {
        return tcs.Task;
    }
}

private static void Main(string[] args)
{
    Foo foo = new Foo();
    foo.ValueChanged()
        .ContinueWith(t =>
        {
            Console.WriteLine(foo.Value);
        }, TaskContinuationOptions.ExecuteSynchronously);

    foo.Value = 5;
}

The Task returned from ValueChanged will be completed the next time that Value is changed. The user of the Foo class can get that returned task and wire up continuations to run on that task based on an operation that has not yet happened. Then, at some point in the future, the value of foo is changed, and the continuation will run. Note that the foo object could be passed to some other function, entirely unknown to Main, that ends up setting the value (to show why you might want to do something like this).

No new thread is needed to create the Task, nor to execute the continuation.

Here’s another example that’s much more practical:

We’ll start with this simple (extension) method that takes a form and returns a Task indicating when that form is next closed:

public static class FormExtensions
{
    public static Task WhenClosed(this Form form)
    {
        var tcs = new TaskCompletionSource<bool>();
        form.FormClosed += (sender, args) => tcs.SetResult(true);
        return tcs.Task;
    }
}

Now we can have this in one of our forms:

private async void button1_Click(object sender, EventArgs args)
{
    Form2 otherForm = new Form2();
    otherForm.Show();

    await otherForm.WhenClosed();

    //take some data from that form and display it on this form:
    textBox1.Text = otherForm.Name;
}

Creating and showing another form never involves the creation of new threads. Both this form and the new form use entirely the one UI thread to be created and modified.

The creation of the Task returned from WhenClosed does not need to create a new thread at all.

When the Task is awaited, no new thread is created. The current method ends and the UI thread is left to go back to processing messages. At some point, that same UI thread will do something that results in the second form being closed. That will result in the continuation of the task running, thus returning us to our button click handler where we set the text of the textbox.

All of this is done entirely with the UI thread, no other threads have been created. And yet we’ve just “waited” (without actually waiting) for a long running operation to finish (the user to put some information into the second form and then close it) without blocking the UI thread, thus keeping the main form responsive.