How to ensure order of async operation calls?

Question

[This appears to be a loooong question but I have tried to make it as clear as possible. Please have patience and help me...]

I have written a test class which supports an Async operation. That operation does nothing but reports 4 numbers:

class AsyncDemoUsingAsyncOperations
{
    AsyncOperation asyncOp;
    bool isBusy;

    void NotifyStarted () {
        isBusy = true;
        Started (this, new EventArgs ());
    }

    void NotifyStopped () {
        isBusy = false;
        Stopped (this, new EventArgs ());
    }

    public void Start () {
        if (isBusy)
            throw new InvalidOperationException ("Already working you moron...");

        asyncOp = AsyncOperationManager.CreateOperation (null);
        ThreadPool.QueueUserWorkItem (new WaitCallback (StartOperation));
    }

    public event EventHandler Started = delegate { };
    public event EventHandler Stopped = delegate { };
    public event EventHandler<NewNumberEventArgs> NewNumber = delegate { };

    private void StartOperation (object state) {
        asyncOp.Post (args => NotifyStarted (), null);

        for (int i = 1; i < 5; i++)
            asyncOp.Post (args => NewNumber (this, args as NewNumberEventArgs), new NewNumberEventArgs (i));

        asyncOp.Post (args => NotifyStopped (), null);
    }
}

class NewNumberEventArgs: EventArgs
{
    public int Num { get; private set; }

    public NewNumberEventArgs (int num) {
        Num = num;
    }
}

Then I wrote 2 test programs; one as console app and another as windows form app. Windows form app works as expected when I call Start repeatedly:

But console app has hard time ensuring the order:

Since I am working on class library, I have to ensure that my library works correctly in all app models (Haven't tested in ASP.NET app yet). So I have following questions:

1. I have tested enough times and it appears to be working but is it OK to assume above code will always work in windows form app?
2. Whats the reason it (order) doesn't work correctly in console app? How can I fix it?
3. Not much experienced with ASP.NET. Will the order work in ASP.NET app?

[EDIT: Test stubs can be seen here if that helps.]

Answer 1

The documentation for AsyncOperation.Post states:

Console applications do not synchronize the execution of Post calls. This can cause ProgressChanged events to be raised out of order. If you wish to have serialized execution of Post calls, implement and install a System.Threading.SynchronizationContext class.

I think this is the exact behavior you’re seeing. Basically, if the code that wants to subscribe to notifications from your asynchronous event wants to receive the updates in order, it must ensure that there is a synchronization context installed and that your AsyncOperationManager.CreateOperation() call is run inside of that context. If the code consuming the asynchronous events doesn’t care about receiving them in the correct order, it simply needs to avoid installing a synchronization context which will result in the “default” context being used (which just queues calls directly to the threadpool which may execute them in any order it wants to).

In the GUI version of your application, if you call your API from a UI thread, you will automatically have a synchronization context. This context is wired up to use the UI’s message queueing system which guarantees that posted messages are processed in order and serially (i.e., not concurrently).

In a Console application, unless if you manually install your own synchronization context, you will be using the default, non-synchronizing threadpool version. I am not exactly sure, but I don’t think that .net makes installing a serializing synchronization context very easy to do. I just use Nito.AsyncEx.AsyncContext from the Nito.AsyncEx nuget package to do that for me. Basically, if you call Nito.AsyncEx.AsyncContext.Run(MyMethod), it will capture the current thread and run an event loop with MyMethod as the first “handler” in that event loop. If MyMethod calls something that creates an AsyncOperation, that operation increments an “ongoing operations” counter and that loop will continue until the operation is completed via AsyncOperation.PostOperationCompleted or AsyncOperation.OperationCompleted. Just like the synchronization context provided by a UI thread, AsyncContext will queue posts from AsyncOperation.Post() in the order it receives them and run them serially in its event loop.

Here is an example of how to use AsyncContext with your demo asynchronous operation:

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Starting SynchronizationContext");
        Nito.AsyncEx.AsyncContext.Run(Run);
        Console.WriteLine("SynchronizationContext finished");
    }

    // This method is run like it is a UI callback. I.e., it has a
    // single-threaded event-loop-based synchronization context which
    // processes asynchronous callbacks.
    static Task Run()
    {
        var remainingTasks = new Queue<Action>();
        Action startNextTask = () =>
        {
            if (remainingTasks.Any())
                remainingTasks.Dequeue()();
        };

        foreach (var i in Enumerable.Range(0, 4))
        {
            remainingTasks.Enqueue(
                () =>
                {
                    var demoOperation = new AsyncDemoUsingAsyncOperations();
                    demoOperation.Started += (sender, e) => Console.WriteLine("Started");
                    demoOperation.NewNumber += (sender, e) => Console.WriteLine($"Received number {e.Num}");
                    demoOperation.Stopped += (sender, e) =>
                    {
                        // The AsyncDemoUsingAsyncOperation has a bug where it fails to call
                        // AsyncOperation.OperationCompleted(). Do that for it. If we don’t,
                        // the AsyncContext will never exit because there are outstanding unfinished
                        // asynchronous operations.
                        ((AsyncOperation)typeof(AsyncDemoUsingAsyncOperations).GetField("asyncOp", BindingFlags.NonPublic|BindingFlags.Instance).GetValue(demoOperation)).OperationCompleted();

                        Console.WriteLine("Stopped");

                        // Start the next task.
                        startNextTask();
                    };
                    demoOperation.Start();
                });
        }

        // Start the first one.
        startNextTask();

        // AsyncContext requires us to return a Task because that is its
        // normal use case.
        return Nito.AsyncEx.TaskConstants.Completed;
    }
}

With output:

Starting SynchronizationContext
Started
Received number 1
Received number 2
Received number 3
Received number 4
Stopped
Started
Received number 1
Received number 2
Received number 3
Received number 4
Stopped
Started
Received number 1
Received number 2
Received number 3
Received number 4
Stopped
Started
Received number 1
Received number 2
Received number 3
Received number 4
Stopped
SynchronizationContext finished

Note that in my example code I work around a bug in AsyncDemoUsingAsyncOperations which you should probably fix: when your operation stops, you never call AsyncOperation.OperationCompleted or AsyncOperation.PostOperationCompleted. This causes AsyncContext.Run() to hang forever because it is waiting for the outstanding operations to complete. You should make sure that your asynchronous operations complete—even in error cases. Otherwise you might run into similar issues elsewhere.

Also, my demo code, to imitate the output you showed in the winforms and console example, waits for each operation to finish before starting the next one. That kind of defeats the point of asynchronous coding. You can probably tell that my code could be greatly simplified by starting all four tasks at once. Each individual task would receive its callbacks in the correct order, but they would all make progress concurrently.

Recommendation

Because of how AsyncOperation seems to work and how it is intended to be used, it is the responsibility of the caller of an asynchronous API that uses this pattern to decide if it wants to receive events in order or not. If you are going to use AsyncOperation, you should document that the asynchronous events will only be received in order by the caller if the caller has a synchronization context that enforces serialization and suggest that the caller call your API on either a UI thread or in something like AsyncContext.Run(). If you try to use synchronization primitives and whatnot inside of the delegate you call with AsyncOperation.Post(), you could end up putting threadpool threads in a sleeping state which is a bad thing when considering performance and is completely redundant/wasteful when the caller of your API has properly set up a synchronization context already. This also enables the caller to decide that, if it is fine with receiving things out of order, that it is willing to process events concurrently and out of order. That may even enable speedup depending on what you’re doing. Or you might even decide to put something like a sequence number in your NewNumberEventArgs in case the caller wants both concurrency and still needs to be able to assemble the events into order at some point.

Answer 2

I use a Queue you can then Enqueue stuff and Dequeue stuff in the correct order. This solved this problem for me.

Answer 3

Unless I am missing something then given the code above I believe there is no way of guaranteeing the order of execution. I have never used the AsyncOperation and AsyncOperationManager class but I looked in reflector and as could be assumed AsyncOperation.Post uses the thread pool to execute the given code asynchronously.

This means that in the example you have provided 4 tasks will be queued to the thread pool synchronously in very quick succession. The thread pool will then dequeue the tasks in FIFO order (first in first out) but it's entirely possible for one of later threads to be scheduled before an earlier one or one of the later threads to complete before an earlier thread has completed its work.

Therefore given what you have there is no way to control the order in the way you desire. There are ways to do this, a good place to look is this article on MSDN.

http://msdn.microsoft.com/en-us/magazine/dd419664.aspx