将同步WCF服务客户端调用转换为异步

Question

I'm learning about Threading, Tasks and asynchronous coding and am trying to apply the concepts to Web Forms applications I work on daily.

So far I have:

• Configured Service reference like so:

• Changed client calls from

   MyServiceClient msc = new MyServiceClient(); try { myData = msc.GetData(); msc.Close(); } catch (Exception) { msc.Abort(); throw; } 

to

    MyServiceClient msc = new MyServiceClient();
    try
    {
         myData =  msc.GetDataAsync().Result;                    
         msc.Close();
    }
    catch (Exception)
    {
         msc.Abort();
         throw;
    }

I am calling the result directly to implictly call .Wait() on the task and keep the code largely as is.

1. Is this correct in order to free up threads in the app pool for other work whilst doing I/O?
2. Do I need to handle exceptions differently?
3. Are Close() and Abort() still necessary and relevant?

Answer 1

I am calling the result directly to implictly call .Wait() on the task and keep the code largely as is.

I don't recommend this at all. In the general case, calling Result or Wait in async code can cause deadlocks (as I explain on my blog). It may work (currently) due to the way svcutil is implementing the methods, but I don't recommend getting into the practice of writing code like this.

It's much better to allow async to grow through the code base:

MyServiceClient msc = new MyServiceClient();
try
{
     myData = await msc.GetDataAsync();                    
     msc.Close();
}
catch (Exception)
{
     msc.Abort();
     throw;
}

1. Is this correct in order to free up threads in the app pool for other work whilst doing I/O?

No. There is really no point to what you're doing. You're not letting the calls be asynchronous at all.

If you use await , then yes, you do get the benefits of asynchronous operations (ie, freeing up the UI thread).

1. Do I need to handle exceptions differently?

If you're using await , then no, your existing code would work fine. If you're using Result , then yes, all your exceptions will be wrapped in an AggregateException .

1. Are Close() and Abort() still necessary and relevant?

Yes.

Answer 2

If calling the async version and waiting for completion was better than the normal way, the framework could just do this transparently for you. The fact that it doesn't do that shows you that this approach is not good.

If I use await I then need to mark each method up the stack as async which is much more work.

That's the deal. You have to change the entire call stack because your thread has to return control to the thread pool while the IO is running. You must exit all function on the stack. Thank god async/await makes this mostly a mechanical exercise.

For that reason you should use async/await in response to a performance need that you otherwise cannot get. Do not use it by default. First determine, whether you actually have too many threads at the moment or not. If not you very likely do not need async at all. Invest your time elsewhere.