title: Detecting misuse of Async/Await: Prevent blocking calls
body: <p>I am working on a scalable game server system and trying to use await/async excessively for this new project. Up till now I managed to run into several pitfalls. I have figured out most of the solutions and developed a "common practice" of how to write async methods such that those pitfalls are easy to detect &amp; avoid. Unfortunately, the following gives me headaches:</p>
  
  <p>1) Example:</p>
  
  <pre><code>async Task&lt;int&gt; RunSqlQuery()
  {
      DbCommand cmd = conn.CreateCommand();
      ...
      cmd.ExecuteReader();
      ...
  }
  </code></pre>
  
  <p>WHOOOM! This is a spoil for several reasons. One, there is an ExecuteReaderAsync(), which would solve the issue. Second, this call will block and stall the internal async framework's worker thread. Not too critical in a desktop environment, but unfortunately, if you have a server with 8000 requests per second, this can seriously harm your performance and it can be terribly hard to track down the precise lines causing the issue. </p>
  
  <p>2) Example:</p>
  
  <pre><code>void ThisHurts()
  {
      someTask.GetAwaiter().GetResult();
  }
  
  async Task&lt;int&gt; RunQuery()
  {
      ...
      lock(something)
      {
          ThisHurts();
      }
      ...
  }
  </code></pre>
  
  <p>I admit this one looks a bit engineered to prove my point but when dealing with lots of code it is a situation that is hard to avoid. Basically calling await in a lock is deadly. Its a catastrophy waiting to happen (literally). There are tons of explanations why, believe them or not, they are true, build something like above and your code will die almost immediately if you have load on your server and the tons of race conditions start chaining together...</p>
  
  <p>So this question is about how to detect those wrong uses of await. Is there some tool like Resharper (which doesn't seem to support most of what I want). I think Microsoft should have tagged all non-blocking methods and force people to either wrap them in an async compatible way or issue a compiler error when trying to call them within async methods. Additionally they could have forced you to use a new "block"-keyword to be added in front of all methods that are not marked non-blocking so that you can stil use them but the shame is immediately displayed.</p>
  
  <p>The main problem I see so far with the async framework is that misuse will only show under heavy load, which is generally terribly hard to debug &amp; trace, because its so much data and the moment you attach a debuigger the problem is gone, because the load is gone. Awesome ;) </p>