Using async methods/lambdas where they are not expected causes unexpected problems. The typical example I discuss with people is TaskFactory.StartNew() because its an easy way to create Tasks and some people reach for that instead of Task.Run(), but I recently came across some code hitting the same problem while creating threads the traditional way.

In this scenario, the code was intended to create some child threads that poll a resource. That resource would sometimes be changed and the master thread would Abort() the child threads and create new ones polling the new resource. But there was a thread leak. Sometimes threads could continue to run after they should have been aborted.

A simplified example looks like this in a console application (I’m not creating the new threads after the abort because its not relevant to the bug in the logic).

We are simply starting two threads, waiting 1 second, and then aborting them. We assume they will stop and not output anything after the “Press ENTER” line. But notice that the two thread functions are asynchronous. What does that mean? As I’ve discussed before you can’t really make any assumptions about the internals of the async code you are calling. You can only know what you are doing yourself around the async operation. What we are doing here is “Start this asynchronous operation on another thread.” We don’t really know when this method will end, or even if it will end on our thread.

So when does our thread end? Can we even abort the operation this way? Not reliably, no.

If the code happens to look like this, we can abort it.

But that’s only because there is no asynchrony actually going on. This will run synchronously on the original thread that called it. But that’s pretty uncommon. More likely there is some asynchrony going on inside it like this

In this case there is an asynchronous delay. This means that all of the iterations of the loop after 0, will happen as asynchronous continuations. Where will they run? It depends on the context. In this example, a console application, they will run on a random thread pool thread.

That means that when I try to abort the thread I created, I’m just aborting the initial thread which is handling the first portion of the method. If the application gets to the await before it gets to the abort, the continuation will already scheduled and will go on oblivious to the fact that the original thread gets aborted. I can’t abort this method using Thread.Abort() because method isn’t just one thread.

Here is what the output looks like. You can see that until the abort happens (immediately before the “Press ENTER” text) the threads are pumping out even and odd numbers. After the abort, the PrintEvenNumbers method is happily continuing its way into infinity.

How to avoid this?

Stick with Tasks and avoid raw Thread code if you can help it. The threading APIs predate the Task/Async APIs by a decade. Mixing the two can result in bugs like this one unless you are extra careful. Task.Run() is your friend for spawning/managing new Tasks, and it is async lambda friendly.

Avoid Thread.Abort() like the plague. There are some unusual cases where it makes sense, but the vast majority of the times I see it, I consider it to be a bug. .NET provides a very clean cooperative cancellation mechanism that is simple and thread safe (the CancellationToken) which should be used instead to signal a child task to tear itself down cleanly and predictably.

Like this:

When cleaning up drive space, the first thing I do is remove the ‘obj’, ‘bin’, and ‘packages’ directories from my development directories. They are temporary and will be rebuilt the next time I build the related project. Because I end up with a lot of little test & sample projects that I don’t refer to often, their binaries and nuget directories are just taking up space.

The reason this is better than doing a Clean Solution is that Clean Solution only removes the outputs of the build. It doesn’t remove the nuget packages which in my case were a significant percentage of my overall dev directory space.

The old way

I used to do this with a little Windows Explorer trick – search filters. It looks like this

“type:folder name:obj” tells explorer to find all the items that have “obj” in the name and are folders. Then I can easily “Select All” and delete. Then repeat for Bin and for Packages. (There is one caveat here that the name search is a substring search, so it will also return directories named “object” too.)

The PowerShell way

But today I got to thinking. I wanted to do that in one step. So here is a PowerShell command that will iterate from the current directory and find all child directories named ‘obj’, ‘bin’, or ‘packages’ and prompt me to delete them.

This publish command will publish the given runtime package to the directory that will ultimately be copied to the drop folder by the rest of the process

On this I step originally wasn’t paying attention to the dialog and put the entire command line in the “tool” text box. That won’t work and you’ll get an error claiming the tool executable can’t be found. That took a while to chase down in my case because a lot of the older posts/forums discuss how to get the dotnet tooling installed into a VSTS Build agent – but it is now built in (Its at C:\program files\dotnet”)

The final build process looks like this

After a build is performed the drop folder looks like thisI left in the original “Copy Files to” step in the build so that I had access to everything that was built as things progressed. But to run things I just need the folders under the “publish” directory

Log in to Ubuntu and download the publish directory

Last step is to run it

So the current overall workflow now is

Update the project on Windows in Visual Studio Community 2015

Check in to Github

VSTS automatically builds, runs unit test, and packages

Download to Windows or Ubuntu to run

Next I’m thinking “What could be better than running a 35 year old text adventure on Azure Service Fabric?”

Like this:

I’ve always been a fan of Zork. If you’ve been playing games awhile (and I mean a whiiiile) then you probably are too. For those of you who aren’t familiar with it, its the original text adventure game. No graphics. Just type actions, and get text feedback. It created the whole genre of Interactive Fiction. You can actually still play it online

Recently I was on vacation and looking for a project and happened to spot Eric Lippert’s blog series describing his implementation of the Zork engine (called a ZMachine) in order to learn OCaml. I realized he was deciphering the mess that is the ZMachine spec that had always seemed a bit opaque to me. Its a seriously interesting bit of engineering to make an actual cross platform virtual machine that ran on the old Apple II TRS-80, Commodores, etc in the 80s. But a lot of their optimizations make for dense and confusing bit twiddling.

I got inspired and started building my own version in C# in an object oriented fashion with current C# techniques and libraries and unit tests.

Like this:

I want to be this guy. This guy who was behind us in line at the grocery store. …I’m standing there while the cashier rings up my cart, and I notice the guy behind me standing innocently doing nothing. Then he picks up a Twinkie from his cart. He starts to smile.He starts to open the Twinkie. He starts to grin. He starts to eat the Twinkie.He is in ecstasy.He continues eating his Twinkie.He is completely oblivious to the outside world.He has no worries.He has no problems.He just has a Twinkie. Enjoying his Twinkie. Enjoying his life.

Like this:

Often, when someone asks “how does this async await stuff actually work”? There is a lot of hand waving or someone says “just use reflection and look at it” but the real compiled code is a complex recursive state machine. So I want to show a (relatively) simplified example that isn’t the real thing but is conceptually correct.

Conceptually, the way I think about it is that the compiler just breaks down my method into a series of tasks that need to be run. Lets start with a simple scenario which has a single await.

We kind of hide the Task by default but if you change it to look like this, you can see we aren’t awaiting the method, we are awaiting the Task returned from the method.

Now we can take the async/await keywords away by breaking the method up into 2 areas – the code that runs before the await, and the code that runs after the await. Because the GetCountAsync() call is async, we can’t run that “after” code immediately. We want to wait until after countTask is complete and then run the “after” code. So what actually runs looks more like this

As you can see, we have taken the “after” code and told it to run as a continuation of the countTask. This means that the GetCountAsync method will run and whenever it gets done, the “after” code will execute. Of course this means we have another task to deal with. The “after” code continuation provides us a new Task object to know when that is done. When that is finished we know that our entire method is finished. So we can return that final Task to the caller of our method so that they will know when we are complete.

Now this is definitely not a complete picture (e.g. we are not dealing with looping or exceptions or managing the UI thread). But I find this a pretty compelling way to demonstrate a couple of key principles.

When you use the async keyword, your method becomes asynchronous because it gets broken into Tasks based on the await keywords in use.

Your async method will return before it completes. Yes, that’s the whole point and is obvious to some people, but here it is shown explicitly because in the final example above, our method isn’t doing any real work except creating the Task chain and then returning.

The code before the first await always runs synchronously. There is no Task management going on until you hit the first await. So if you have a 10 second operation before the first await, the method will take 10 seconds and then hook up the task chain and return.

This is why your callstack looks different when debugging. The “after” code is not being called from DoWorkWithoutAwait(). It is being called directly from the .NET Task infrastructure as a continuation of the previous task.

Taking that a bit further

Lets take that concept and apply it to a more realistic method which contains multiple awaits.

In the same steps, we can think of this as dividing our method up into a number of intermediate Tasks separated by the await keywords.

Again, this just demonstrates those same points that I see some developers forget or struggle with. When I see a series of await keywords, I’m thinking about how that method gets broken down into individual tasks – not how it is going to run as a single unit. This helps me remember that even if this ends up running on a single thread, the fact that is gets chunked up means that other scheduled code can potentially run in between my method’s various sections. You can also see this concept graphically in this previous post.

I talk to a lot of developers who are either new to .NET or are moving from an older version to the newer platform and tools. As such I’m always trying to think of new ways to describe the nature of Tasks vs Threads and async vs parallel. Modern .NET development is steeped in the async/await model and async/await is built on the Task model. So understanding these concepts is key to long term success building apps in .NET.

In order to help visualize this I built a simple WPF application that displays a chart of an application’s activity. I want to display some of the potential variations in behavior of what appear to be a simple set of async tasks.

Take the following method

This is a simple event handler which is going to call 3 asynchronous methods and then wait for all three to complete and then print out how long it took to do the whole operation. How many threads are there? Some people will assume only 1, some will assume 3. Like everything in software, it depends.

The DoWorkAsync() method just runs a loop. Each time around the loop, it will do some sort of asynchronous task and then do some busy “work” for some amount of time, then it will draw a rectangle on the screen representing the time that it spent doing that “work.” (This is analogous to making a web service call and then doing some local processing on the data returned from the service.) In this way we can easily see (a) when the work is being performed, and (b) whether the work overlaps with other task’s work. If it does, then we are running on multiple threads. The work we are concerned with is our code (e.g. the local data processing) – not the thing being waited on (the async web service), so each bar in the app will represent the local processing.

The first case is the simplest, the method is marked as async but we really don’t have any asynchronous work going on inside it. In this case, the method is actually going to actually run to completion synchronously, meaning that the tasks above (in the event handler) will all be complete immediately upon creation and there wont be any new threads. They will each just run one right after the other.

In this image, the vertical axis is time. So first the red task ran, then the blue task ran, then the green task ran. It took 5 seconds total because 5 loops * (200ms + 300ms+ 500ms) = 5 seconds. You can also just make out the faint white lines of each individual iteration of the loops. But only 1 thread was used to run all three tasks.

Now lets make one change. Add an asynchronous operation where the //TODO is. Typically this might be a web service call or reading from a file, but for our purposes we will just use Task.Delay()

The only change here is the addition of the Task.Delay to the beginning of the loop. This will cause the method to not complete synchronously because it is going to do an asynchronous wait at the start of every iteration of the loop (simulating our async service call wait). Now look at the result.

It still took about the same amount of time, but the iterations are interleaved. They are not overlapping each other though because we are still on the same thread. When you “await” an asynchronous task, the rest of your method will continue running in the same context that it started on. In WPF, that context is the UI thread. So while the red task is doing its delay, the blue and green tasks are running on the UI thread. When the red task is done delaying and wants to continue, it cant until the UI thread becomes available so it just queues up until its turn comes back around.

(Also notice that we didn’t add 1.5 seconds (100ms * 5 iterations * 3 tasks) to the total operation time. That’s the async benefit, we were able to overlap the waiting time of one task with the work time of other tasks by sharing the UI thread while we were waiting.)

But sometimes, this interleaving doesn’t happen. What if you have an asynchronous task that finishes so fast, it might as well be synchronous?

When the async plumbing goes to work, it first checks to see if the async operation is completed. Task.Delay(0) will be completed immediately, and as such will be treated like a synchronous call.

Well that puts us back to where we started. All 5 red iterations happen first because there is no asynchronous work to wait on.

Everything happens on the same thread context unless you tell it not to. Enter ConfigureAwait().

ConfigureAwait(false) tells the async plumbing to ignore the thread context, and just continue on any old thread it wants. This means that as soon as the red task is done with its delay, it doesn’t have to wait for the UI thread to be available. It runs on a random threadpool thread.

Two things to notice here. First, since they are not bound to only running on the UI thread, they are running overlapped at the same time on multiple threads. Second, it only took 3 seconds to complete all three because they were able to fan out across multiple threads. (You can explicitly see the Task.Delays here because they are the white gaps between each bar)

Now what happens if we combine Task.Delay(0) with ConfigAwait(false)?

Now we have a async task that will actually complete synchronously, but we are telling it not to bother with affinity for the threading context.

Summary

Look at this from the perspective of the original event handler above. The event handler has absolutely no idea whether its tasks are going to run on one thread or multiple threads. All it knows is that it has requested 3 potentially asynchronous tasks to be completed. The underlying implementation will determine whether additional threads come in to play or not. And whether you have multiple threads determines whether you run in parallel or not. So you need to be prepared for either behavior when writing and debugging your app because in the end, it just depends.

(Side note: The parallel behavior above is a side effect of the async/await thread context affinity in the WPF task scheduler. It is not guaranteed and the behavior may vary depending with different task schedulers. It should not be relied upon as a method to create other threads. If you require something to run in parallel, use Task.Run())