Await forever – deadlocked so easily

Async/Await simplifies async code, use it everywhere and life becomes so simple right?
While this is true I’ve seen situations where users either chose to, or had to, mix async and non async code and got themselves into a world of problems.

 

One problem I’ve seen time over time is with Windows Desktop applications where a simple blocking call on a Task can deadlock an application entirely, here I demonstrate the problem with a contrived Windows Forms example.

Application simply downloads some html asynchronously and displays it in a web browser

Implementation of async function is:

(Let’s ignore the urge to make the click handler async, imagine the async call was in the form constructor if you must)


How can such a simple bit of code deadlock the windows application?

Well the problem occurs because of how Async/Await state machines work.
I’m really going to simplify this explanation as I want people to grasp it (so grit ur teeth if you already know the detail Winking smile)

 

The async keyworks is simply a compile instruction that doesn’t do much so lets ingore that and focus on the await call

The await calls an async function then waits on a call back, when the call back occurs the code resumes to the next step…

ok so far so good, this is what we expect… simple right…wrong!

 

A quick recap of windows UI threads and messages

Before we continue let’s have a quick recap of windows UI threads and message loops.
A message loop is an obligatory section of code in every program that uses a graphical user interface under Microsoft Windows. Windows programs that have a GUI are event-driven. Windows maintains an individual message queue for each thread that has created a window.

Now as anyone working on a windows application knows you always call any code that updates the UX on the GUI thread, try with any other threads and you’ll get presented with a cross thread exception.

Windows forms application code can call Invoke/BeginInvoke on a windows control and execute the code back on the GUI Thread, in WPF we would use a dispatcher, in UWP/Wintr it’s something else.

Another approach is to use the SyncronizationContext contruct, this is aware if it should call Invoke or Dispatch or something else on our behalf.

 

Back to await

The callback I mentioned above is smart in that it tries to use the existing Syncronization context if it exists, so when that await finally returns we’re back on the GUI thread can can update the UX without those pesky errors.
In our calling code above we never left the GUI thread as we were blocked on the Result of the task.

The crux of the problem is that the await call back puts a message on the windows message queue to tell it to continue, but the message queue is bocked in that call to .Result on the task, so we’re well and truly deadlocked.

 

Solutions

I’ll avoid telling you to embrace async/await everywhere! and offer some alternate solutions..

1) ConfigureAwait(false)


This works as it tells the task not to continue on the current syncroniztion context (which let’s remember is the GUI thread), another context is used to complete the async await state machine call back and allow the task to be completed.

2) Run on another syncronization context you create

 

3) Use Async/Await everywhere

Summary

This is a very dumbed down explanation of how you might encounter a deadlock with async await.

If it happens then don’t panic it can be easily fixed once you know what’s happening, best practise is nearly never to work around the problem and always use async await entirely.

Standard documentation is great there are lots for really good articles floating about: e.g. https://devblogs.microsoft.com/dotnet/configureawait-faq/

Azure Arc Server Registration Error


Today while adding a new server to an Azure subscription I encountered the following error:

The subscription is not registered to use namespace 'Microsoft.HybridCompute'

In this video I show you how register the Hybrid Compute provider in your subscription to overcome this obstacle.

Bitbucket- Pipelines -Terraform - Private Modules

So you’ve started using terraform

You’ve progressed to creating terraform modules

You’ve put your module in a private bitbucket repo

Now you want to access it from a bitbucket build pipeline and you see the following

Solution

In my case I reached out to one of my friendly devops colleagues  @BlnaryMlke who showed me how ssh keys and git hang together, I don’t know if i should be ashamed to say I’ve never used git with ssh keys until today.

Armed with this new knowledge I set off to do the same in my bitbucket pipeline only to discover that Bitbucket has some primary support for this scenario!

What follows are the steps required in a bitbucket pipeline in order to to use a private git bitbucket repo that contains a terraform module

Show me

1) First create a new key in the the project that contains your pipeline (i.e. the project that is including the terraform module), you’ll find this option under project settings, pipelines/ssh keys

Image shows that I’ve added a new Key and then added bitbucket.org (fetch gets the fingerprint)

2) Now add the public key to your bitbucket git repo that contains the terraform module, to do this you go to the project settings and choose access keys then add

3) Lastly, you’ll need to configure your terraform module source with the following format

That’s it, huge thanks again to @BlnaryMlke for setting me on the right path

4) Bonus Step: If you wish to work outside the bitbucket pipeline and don’t want to use ssh keys but rather your OAuth token you can configure git insteadof to automagically redirect ssh to http

Azure Key Vault References

In this video I show you how move application secrets into Azure Key Vault without any code changes.I do this by using a vault access policy.

Note: You'll have to ignore my managed identity references in this video I didn't use them.

Azure Managed Identities

In this video I show you how to leverage Azure Managed Identities to allow access between Azure resources.

(excuse the audio quality.. i need to improve on this)

Flexing those Java generic PECS

I believe I’ve previously covered c# generics covariance and contravariance in the past, now it’s javas turn

As you may or may not know

The term PECS stands for “Producer Extends, Consumer Super,” which is an odd acronym coined by Joshua Block in his Effective Java book, but provides a mnemonic on what to do. It means that if a parameterized type represents a producer, use extends. If it represents a consumer, use super. If the parameter is both, don’t use wildcards at all—the only type that satisfies both requirements is the explicit type itself.

Covariance in java uses the extends keyword (yes even with interfaces), e.g. List<? extends Number> accommodates all types that derive from Number


Contravariance on the other hand uses the super keyword e.g. List<? super Number> accommodates all the types that Number derives from and of course number itself.

So what exactly is PECS recommending we do?

  • Use extends when you only get values out of a data structure
  • Use super when you only put values into a data structure
  • Use the exact type when you plan on doing both