Truly asynchronous WCF service

Question

I am implementing an asynchronous service. After evaluating Microsoft's example, I am wondering if their approach is truly asynchronous. I am pretty sure it is, but some of the samples I've seen online and the AsyncCallback parameter causes me to wonder.

According to the example, we need to implement the Begin and End method pair like this:

public IAsyncResult BeginGetAcmeAnvil(AsyncCallback callback, object state)
{
  // Starts synchronous task
  var acmeAsyncResult = new AcmeAsyncResult<Anvil>
  {
     Data = new Anvil()
  };      
  return acmeAsyncResult;
}

public Anvil EndGetAcmeAnvil(IAsyncResult result)
{
  var acmeAsyncResult = result as AcmeAsyncResult<Anvil>;

  return acmeAsyncResult != null
    ? acmeAsyncResult.Data
    : new Anvil();
}

Pretty straightforward, but why do we have an AsyncCallback parameter? Shouldn't we do a call to callback which will in turn trigger the End method?

This is what I have in mind:

public delegate void AsyncMethodCaller(AcmeAsyncResult<Anvil> acmeAsyncResult, 
                                       AsyncCallback callback);

public IAsyncResult BeginGetAcmeAnvil(AsyncCallback callback, object state)
{
  var acmeAsyncResult = new AcmeAsyncResult<Anvil>();
  var asyncMethodCaller = new AsyncMethodCaller(GetAnvilAsync);

  // Starts asynchronous task
  asyncMethodCaller.BeginInvoke(acmeAsyncResult, callback, null, null);

  return acmeAsyncResult;
}

private void GetAcmeAnvilAsync(AcmeAsyncResult<Anvil> acmeAsyncResult,
                               AsyncCallback callback)
{
  acmeAsyncResult.Data = new Anvil();
  callback(acmeAsyncResult);  // Triggers EndGetAcmeAnvil
}

public Anvil EndGetAcmeAnvil(IAsyncResult result)
{
  var acmeAsyncResult = result as AcmeAsyncResult<Anvil>;

  return acmeAsyncResult != null
    ? acmeAsyncResult.Data
    : new Anvil();
}

I did some load testing using loadUI, but there was no obvious performance changes.

Answer 1

I found a good article explaining how to get the best performance out of your Async WCF service.

The gist is:

1. don't do heavy work in the Begin method, and
2. do make the callback to trigger the End method.

Here's an extract from the text:

For best performance, here are two principles when you call/implement the above asynchronous pattern:

• Principle 1: Do not do heavy-weighted work inside the Begin method...

  The reason for this is that you should return the calling thread as soon as possible so that the caller can schedule other work. If it’s a UI thread, the application needs to use the thread to respond to user inputs. You should always put heavy operations in a different thread if possible.

• Principle 2: Avoid calling End method on the same thread of the Begin method.

  The End method is normally blocking. It waits for the operation to complete. If you implement the End method, you would see that it actually calls IAsyncResult.WaitHandle.WaitOne(). On the other hand, as a normal implementation, this WaitHandle is a delay allocated ManualResetEvent. As long as you don’t call it, it would be not allocated at all. For fast operations, this is pretty cheap. However, once End is called, you would have to allocate it. The right place to call End is from the callback of the operation. When the callback is invoked, it means that the blocking work is really completed. At this point, you can call End to get data retrieved without sacrificing performance.

Answer 2

I think the main reason its separated like this is that the WCF runtime is handling the thread synchronization as opposed to you having to handle it manually.

If you were invoking the end method via callback, you would have to handle the synchronization which makes the pattern quite a bit more complex (as you can see in your coding examples). The goal of this pattern is not for you to really be aware of the threading stuff, you just want to code your long running operation without having to think about the implementation details of the threading.