Asynchronous programming model in .NET makes it very easy
for developers to write event based asynchronous pattern (EAP) code starting
.NET version 4.5. We have been trained for long enough by .NET programming
practices to use event based pattern for any asynchronous work. For example,
you want to perform a long running operation. When calling this long running
function, you don’t want your client code to make a blocking call; instead a
very famous pattern that many architects suggests here is to ask you client to
pass a callback function or delegate and that callback function will be called as
soon as this long running operation is over. This is nothing but the EAP
pattern.
As shown in following example, function “client” makes a
call to “longfunction” and waits for the long function to complete. This is a
blocking call.
private Task<string> CallLongRunningService()
{
var client = new ServiceReference1.Service1Client();
// blocking call where main thread is blocked
client.CallLongRunningService();
}
Now instead of just waiting for “longfunction” to complete, “client”
function wants to do some other stuff. Here many architects would suggest to
use EAP pattern and call the long function asynchronously.
So we refactor “CallLongRunningService”
to “CallLongRunningServiceWithCallback”
and ask a callback function to be called when long function is complete.
private void CallLongRunningServiceWithCallback()
{
var client = new ServiceReference1.Service1Client();
client.LongFunctionCallback
+= LongFunctionCallback;
client.RunLongFunctionAsync();
}
private void LongFunctionCallback(CallbackArgs
args)
{
// set the result in some local variable. Basically store the result so
that others
// can access it
m_result = args.Result;
}
As you can guess “client” function also need to be
refactored to consume the refactored “CallLongRunningServiceWithCallback”
and reconcile its logic with the callback function. Now we have split the logic
into two functions, main function and callback function.
Now this is where TaskCompletionSource and Task Parallel
Library TPL comes to rescue. Using TaskCompletionSource you can refactor the
above code as follows:
private Task<string> CallLongRunningServiceWithCallback()
{
var tcs = new TaskCompletionSource<string>();
var client = new ServiceReference1.Service1Client();
client.LongFunctionCallback
+= (o, args) =>
{
if
(args.Error != null)
{
tcs.TrySetException(args.Error);
return;
}
if (args.Cancelled)
{
tcs.TrySetCanceled();
return;
}
tcs.TrySetResult(args.Result);
};
client.RunLongFunctionAsync();
// Do some other work…
return tcs.Task;
}
Client application will get the task as return parameter and
will have to call task.Result to get the result from long running function. In
the above see the comment line “Do some other work…”. This is where you can do
something else while the long function is doing its job. Following is the code
you will write to consume the long running function with callback.
Task<string> t =
CallLongRunningFunctionWithCallback();
Console.WriteLine(t.Result);
Where is the blocking call here? In above lines of code when
you call t.Result it’s a blocking call on current thread. You need this anyway
because we don’t know how long the long function will take to complete. But the
best thing about this pattern that I allows us to not just wait but we can
carry other activities during the function is running. Also see TPL code is
much simpler than our earlier when callback was a separate function. TPL provides TaskCompletionSource to help us track
the result of the async task in a consistent way across the projects.
