{"id":2763,"date":"2008-02-29T15:20:00","date_gmt":"2008-02-29T15:20:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/pfxteam\/2008\/02\/29\/implementing-the-asynchronous-programming-model-with-futuret\/"},"modified":"2008-02-29T15:20:00","modified_gmt":"2008-02-29T15:20:00","slug":"implementing-the-asynchronous-programming-model-with-futuret","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/implementing-the-asynchronous-programming-model-with-futuret\/","title":{"rendered":"Implementing the Asynchronous Programming Model with Future"},"content":{"rendered":"

One of our design goals for the Task Parallel Library is to integrate well into existing asynchronous mechanisms in the .NET Framework.  And one of the most common concurrency-related patterns in the .NET Framework is the Asynchronous Programming Model (APM), which typically manifests as a BeginXx method that kicks off an asynchronous operation and returns an IAsyncResult, along with an EndXx method that accepts an IAsyncResult and returns the computed value.<\/p>\n

Implementing this for computationally intensive asynchronous operations can be done with System.Threading.Tasks.Future<T>, as Future<T> derives from System.Threading.Tasks.Task, and Task implements IAsyncResult.  Imagine you had a class used for computing the value of pi to an arbitrary number of decimal places:<\/p>\n

\n

public<\/span> class<\/span> PI
<\/span><\/span>{
<\/span>    <\/span>public<\/span> string<\/span> Calculate(int<\/span> decimalPlaces) { … }<\/span>
<\/span>}<\/span><\/p>\n<\/blockquote>\n

We can add BeginCalculate and EndCalculate methods that provide a trimmed-down implementation of the APM for Calculate with only a few lines of code:<\/p>\n

\n

public<\/span> class<\/span> PI
<\/span><\/span>{
<\/span>    …<\/p>\n

<\/span><\/p>\n

  <\/p>\n

<\/span>  <\/span>public<\/span> IAsyncResult<\/span> BeginCalculate(int<\/span> decimalPlaces)
<\/span>    <\/span>{
<\/span>        <\/span>return<\/span> Future<\/span>.Create(() => Calculate(decimalPlaces));
<\/span>    <\/span>}<\/span><\/p>\n

 
<\/p>\n

<\/span>
    <\/span>public<\/span> string<\/span> EndCalculate(IAsyncResult<\/span> ar)
<\/span>    <\/span>{
<\/span>        <\/span>var<\/span> f = ar as<\/span> Future<\/span><string<\/span>>;
<\/span>        <\/span>if<\/span> (f == null<\/span>) throw<\/span> new<\/span> ArgumentException<\/span>(“ar”<\/span>);
<\/span>        <\/span>return<\/span> f.Value;
<\/span>    <\/span>}
<\/span>}<\/span><\/p>\n<\/blockquote>\n

However, the full APM pattern dictates that BeginXx should also accept an AsyncCallback that is invoked when the operation completes, along with some user-defined state.  The AsyncCallback addition is easy to implement with the current design of Future<T>:<\/p>\n

\n

public<\/span> IAsyncResult<\/span> BeginCalculate(
    int<\/span> decimalPlaces, AsyncCallback<\/span> ac)
<\/span>{
<\/span>    <\/span>var<\/span> f = Future<\/span>.Create(() => Calculate(decimalPlaces));
<\/span>    <\/span>if<\/span> (ac != null<\/span>) f.Completed += delegate<\/span> { ac(f); };
<\/span>    <\/span>return<\/span> f;
<\/span>}<\/span><\/p>\n<\/blockquote>\n

I simply register with the Future<T>’s Completed event such that when the Future<T> completes, it invokes the AsyncCallback.  Easy enough.  Unfortunately, with the current design of Future<T>, supporting the state argument is more difficult, since unlike Task, none of the factories for Future<T> accept an arbitrary state argument (this is something we’re planning to rectify).  For now with the current CTP bits, you can work around this by creating your own small wrapper for the Future<T> and the state object:<\/p>\n

\n

private<\/span> class<\/span> FutureWithState<\/span><T> : IAsyncResult
<\/span><\/span>{
<\/span>    <\/span>public<\/span> IAsyncResult<\/span> Future;
<\/span>    <\/span>public<\/span> object<\/span> State;<\/span><\/p>\n

 <\/p>\n

<\/span>    <\/span>public<\/span> object<\/span> AsyncState { get<\/span> { return<\/span> State; } }
<\/span>    <\/span>public<\/span> WaitHandle<\/span> AsyncWaitHandle {
        get<\/span> { return<\/span> Future.AsyncWaitHandle; } }
<\/span>    <\/span>public<\/span> bool<\/span> CompletedSynchronously {
        <\/span>get<\/span> { return<\/span> Future.CompletedSynchronously; } }
<\/span>    <\/span>public<\/span> bool<\/span> IsCompleted {
        get<\/span> { return<\/span> Future.IsCompleted; } }
<\/span>}<\/span><\/p>\n<\/blockquote>\n

The modifications to our implementations of BeginCalculate and EndCalculate to support state are then very straightforward:<\/p>\n

\n

public<\/span> IAsyncResult<\/span> BeginCalculate(
    int<\/span> decimalPlaces, AsyncCallback<\/span> ac, object<\/span> state)
<\/span>{
<\/span>    <\/span>var<\/span> f = Future<\/span>.Create(() => Calculate(decimalPlaces));<\/span>
<\/span>    <\/span>var fws = <\/font><\/span>new<\/span> FutureWithState<\/span><string<\/span>> {
        Future = f, State = state };
<\/span>    <\/span>if<\/span> (ac != null<\/span>) f.Completed += delegate<\/span> { ac(fws); };
    return <\/span>fws;<\/span><\/span>
<\/span>}<\/p>\n

<\/span>public<\/span> string<\/span> EndCalculate(IAsyncResult<\/span> ar)
<\/span>{
<\/span>    <\/span>var<\/span> f = ar as<\/span> FutureWithState<\/span><string<\/span>>;
<\/span>    <\/span>if<\/span> (f == null<\/span>) throw<\/span> new<\/span> ArgumentException<\/span>(“ar”<\/span>);
<\/span>    <\/span>return<\/span> f.Future.Value;
<\/span>}<\/span><\/p>\n<\/blockquote>\n

This same container approach can work for scenarios where you want to store more arbitrary state with your IAsyncResult.<\/p>\n

Note, too, that Future<T> can also be used for situations where the asynchronous work isn’t computationally intensive.  Consider the System.Net.NetworkInformation.Ping class that was introduced in the .NET Framework 2.0.  Rather than following the APM pattern, Ping derives from Component and follows the Event-based Asynchronous Pattern (EAP).  So rather than exposing BeginSend and EndSend methods that deal with IAsyncResults, it exposes a SendAsync method that returns void, along with a PingCompleted event that is raised when the asynchronous ping send operation completes.  What if we wanted to use asynchronous pings, but we wanted to expose them through the APM pattern.  We could easily implement this with Future<T> as follows:<\/p>\n

\n

public<\/span> class<\/span> MyPing
<\/span><\/span>{
<\/span>    <\/span>public<\/span> IAsyncResult<\/span> BeginPing(string<\/span> host)
<\/span>    <\/span>{
<\/span>        <\/span>return<\/span> Future<\/span>.Create(() => new<\/span> Ping<\/span>().Send(host));
<\/span>    <\/span>}<\/span><\/p>\n

 <\/p>\n

<\/span>    <\/span>public<\/span> PingReply<\/span> EndPing(IAsyncResult<\/span> ar)
<\/span>    <\/span>{
<\/span>        <\/span>var<\/span> f = ar as<\/span> Future<\/span><PingReply<\/span>>;
<\/span>        <\/span>if<\/span> (f == null<\/span>) throw<\/span> new<\/span> ArgumentException<\/span>(“ar”<\/span>);
<\/span>        <\/span>return<\/span> f.Value;
<\/span>    <\/span>}
<\/span>}<\/span><\/p>\n<\/blockquote>\n

but this has some serious downsides: foremost, the implementation of Send is not computationally intensive, and yet the Future<T> is going to be using and blocking a thread to do a synchronous send.  What we really want to do is take full advantage of Ping’s asynchronous send implementation.  And we can do that by using Future<T>’s “promise” capabilities:<\/p>\n

\n

public<\/span> class<\/span> MyPing
<\/span><\/span>{
<\/span>    <\/span>public<\/span> IAsyncResult<\/span> BeginPing(string<\/span> host, AsyncCallback<\/span> ac)
<\/span>    <\/span>{<\/span>
<\/span>        <\/span>var<\/span> f = Future<\/span><PingReply<\/span>>.Create();
        <\/span>if<\/span> (ac != null<\/span>) f.Completed += delegate<\/span> { ac(f); };
<\/span>
       <\/span> <\/span>Ping<\/span> p = new<\/span> Ping<\/span>();<\/span>
<\/span>        <\/span>p.PingCompleted += (sender, state) =>
<\/span>        <\/span>{
<\/span>            <\/span>if<\/span> (state.Error != null<\/span>) f.Exception = state.Error;
<\/span>            <\/span>else<\/span> f.Value = state.Reply;<\/span>
        <\/span>};
        p.SendAsync(host, null<\/span>);
<\/span>
<\/span>        <\/span>return<\/span> f;
<\/span>    <\/span>}<\/span><\/p>\n

 <\/p>\n

<\/span>    <\/span>public<\/span> PingReply<\/span> EndPing(IAsyncResult<\/span> ar)
<\/span>    <\/span>{
<\/span>        <\/span>var<\/span> f = ar as<\/span> Future<\/span><PingReply<\/span>>;
<\/span>        <\/span>if<\/span> (f == null<\/span>) throw<\/span> new<\/span> ArgumentException<\/span>(“ar”<\/span>);
<\/span>        <\/span>return<\/span> f.Value;
<\/span>    <\/span>}
<\/span>}<\/span><\/p>\n<\/blockquote>\n

The Future<T> I create here has no delegate associated with it.  Instead, it allows its Value and Exception properties to be set (only once), and someone waiting on Future<T>’s Value will block until either Exception or Value is set.  I take advantage of that by setting these properties in the PingCompleted event handler.  With very little code, I now can get a fully-working IAsyncResult that represents an asynchronous ping, where the original asynchronous behavior was exposed through a different mechanism.<\/p><\/p>\n","protected":false},"excerpt":{"rendered":"

One of our design goals for the Task Parallel Library is to integrate well into existing asynchronous mechanisms in the .NET Framework.  And one of the most common concurrency-related patterns in the .NET Framework is the Asynchronous Programming Model (APM), which typically manifests as a BeginXx method that kicks off an asynchronous operation and returns […]<\/p>\n","protected":false},"author":360,"featured_media":58792,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[7908],"tags":[7911,7909,7912],"class_list":["post-2763","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-pfxteam","tag-code-samples","tag-parallel-extensions","tag-task-parallel-library"],"acf":[],"blog_post_summary":"

One of our design goals for the Task Parallel Library is to integrate well into existing asynchronous mechanisms in the .NET Framework.  And one of the most common concurrency-related patterns in the .NET Framework is the Asynchronous Programming Model (APM), which typically manifests as a BeginXx method that kicks off an asynchronous operation and returns […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/2763","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/360"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=2763"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/2763\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/58792"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=2763"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=2763"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=2763"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}