Export (0) Print
Expand All
2 out of 3 rated this helpful - Rate this topic

TPL and Traditional .NET Framework Asynchronous Programming

The .NET Framework provides the following two standard patterns for performing I/O-bound and compute-bound asynchronous operations:

  • Asynchronous Programming Model (APM), in which asynchronous operations are represented by a pair of Begin/End methods such as FileStream.BeginRead and Stream.EndRead.

  • Event-based asynchronous pattern (EAP), in which asynchronous operations are represented by a method/event pair that are named OperationNameAsync and OperationNameCompleted, for example, WebClient.DownloadStringAsync and WebClient.DownloadStringCompleted. (EAP was introduced in the .NET Framework version 2.0.)

The Task Parallel Library (TPL) can be used in various ways in conjunction with either of the asynchronous patterns. You can expose both APM and EAP operations as Tasks to library consumers, or you can expose the APM patterns but use Task objects to implement them internally. In both scenarios, by using Task objects, you can simplify the code and take advantage of the following useful functionality:

  • Register callbacks, in the form of task continuations, at any time after the task has started.

  • Coordinate multiple operations that execute in response to a Begin_ method, by using the ContinueWhenAll and ContinueWhenAny methods, or the WaitAll method or the WaitAny method.

  • Encapsulate asynchronous I/O-bound and compute-bound operations in the same Task object.

  • Monitor the status of the Task object.

  • Marshal the status of an operation to a Task object by using TaskCompletionSource<TResult>.

Both the System.Threading.Tasks.TaskFactory and System.Threading.Tasks.TaskFactory<TResult> classes provide several overloads of theFromAsync andFromAsyncmethods that let you encapsulate an APM Begin/End method pair in one Task instance or Task<TResult> instance. The various overloads accommodate any Begin/End method pair that have from zero to three input parameters.

For pairs that have End methods that return a value (Function in Visual Basic), use the methods in TaskFactory<TResult>, which create a Task<TResult>. For End methods that return void (Sub in Visual Basic), use the methods in TaskFactory, which create a Task.

For those few cases in which the Begin method has more than three parameters or contains ref or out parameters, additional FromAsync overloads that encapsulate only the End method are provided.

The following code example shows the signature for the FromAsync overload that matches the FileStream.BeginRead and FileStream.EndRead methods. This overload takes three input parameters, as follows.

public Task<TResult> FromAsync<TArg1, TArg2, TArg3>(
    Func<TArg1, TArg2, TArg3, AsyncCallback, object, IAsyncResult> beginMethod, //BeginRead
     Func<IAsyncResult, TResult> endMethod, //EndRead
     TArg1 arg1, // the byte[] buffer
     TArg2 arg2, // the offset in arg1 at which to start writing data
     TArg3 arg3, // the maximum number of bytes to read 
     object state // optional state information
    ) 

The first parameter is a Func<T1, T2, T3, T4, T5, TResult> delegate that matches the signature of the FileStream.BeginRead method. The second parameter is a Func<T, TResult> delegate that takes an IAsyncResult and returns a TResult. Because EndRead returns an integer, the compiler infers the type of TResult as Int32 and the type of the task as Task. The last four parameters are identical to those in the FileStream.BeginRead method:

  • The buffer in which to store the file data.

  • The offset in the buffer at which to begin writing data.

  • The maximum amount of data to read from the file.

  • An optional object that stores user-defined state data to pass to the callback.

If you require access to the data in the file, as opposed to just the number of bytes, the FromAsync method is not sufficient. Instead, use Task, whose Result property contains the file data. You can do this by adding a continuation to the original task. The continuation performs the work that would typically be performed by the AsyncCallback delegate. It is invoked when the antecedent completes, and the data buffer has been filled. (The FileStream object should be closed before returning.)

The following example shows how to return a Task that encapsulates the BeginRead/EndRead pair of the FileStream class.

const int MAX_FILE_SIZE = 14000000;
public static Task<string> GetFileStringAsync(string path)
{
    FileInfo fi = new FileInfo(path);
    byte[] data = null;
    data = new byte[fi.Length];

    FileStream fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read, data.Length, true);

    //Task<int> returns the number of bytes read
    Task<int> task = Task<int>.Factory.FromAsync(
            fs.BeginRead, fs.EndRead, data, 0, data.Length, null);

    // It is possible to do other work here while waiting 
    // for the antecedent task to complete. 
    // ... 

    // Add the continuation, which returns a Task<string>.  
    return task.ContinueWith((antecedent) =>
    {
        fs.Close();

        // Result = "number of bytes read" (if we need it.)
        if (antecedent.Result < 100)
        {
            return "Data is too small to bother with.";
        }
        else
        {
            // If we did not receive the entire file, the end of the 
            // data buffer will contain garbage. 
            if (antecedent.Result < data.Length)
                Array.Resize(ref data, antecedent.Result);

            // Will be returned in the Result property of the Task<string> 
            // at some future point after the asynchronous file I/O operation completes. 
            return new UTF8Encoding().GetString(data);
        }
    });
}

The method can then be called, as follows.


Task<string> t = GetFileStringAsync(path);          

// Do some other work: 
// ... 

try
{
     Console.WriteLine(t.Result.Substring(0, 500));
}
catch (AggregateException ae)
{
    Console.WriteLine(ae.InnerException.Message);
}            

In typical IAsyncResult operations, if your AsyncCallback delegate requires some custom state data, you have to pass it in through the last parameter in the Begin method, so that the data can be packaged into the IAsyncResult object that is eventually passed to the callback method. This is typically not required when the FromAsync methods are used. If the custom data is known to the continuation, then it can be captured directly in the continuation delegate. The following example resembles the previous example, but instead of examining the Result property of the antecedent, the continuation examines the custom state data that is directly accessible to the user delegate of the continuation.

public Task<string> GetFileStringAsync2(string path)
{             
    FileInfo fi = new FileInfo(path);
    byte[] data = new byte[fi.Length];                       
    MyCustomState state = GetCustomState();
    FileStream fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read, data.Length, true);
    // We still pass null for the last parameter because 
    // the state variable is visible to the continuation delegate.
    Task<int> task = Task<int>.Factory.FromAsync(
            fs.BeginRead, fs.EndRead, data, 0, data.Length, null);

    return task.ContinueWith((antecedent) =>
    {
        // It is safe to close the filestream now.
        fs.Close();

        // Capture custom state data directly in the user delegate. 
        // No need to pass it through the FromAsync method. 
        if (state.StateData.Contains("New York, New York"))
        {
            return "Start spreading the news!";
        }
        else
        {
            // If we did not receive the entire file, the end of the 
            // data buffer will contain garbage. 
            if (antecedent.Result < data.Length)
                Array.Resize(ref data, antecedent.Result);

            // Will be returned in the Result property of the Task<string> 
            // at some future point after the asynchronous file I/O operation completes. 
            return new UTF8Encoding().GetString(data);
        }
    });

}

The static ContinueWhenAll and ContinueWhenAny methods provide added flexibility when used in conjunction with the FromAsync methods. The following example shows how to initiate multiple asynchronous I/O operations, and then wait for all of them to complete before you execute the continuation.

public Task<string> GetMultiFileData(string[] filesToRead)
{
    FileStream fs;
    Task<string>[] tasks = new Task<string>[filesToRead.Length];
    byte[] fileData = null;
    for (int i = 0; i < filesToRead.Length; i++)
    {
        fileData = new byte[0x1000];
        fs = new FileStream(filesToRead[i], FileMode.Open, FileAccess.Read, FileShare.Read, fileData.Length, true);

        // By adding the continuation here, the  
        // Result of each task will be a string.
        tasks[i] = Task<int>.Factory.FromAsync(
                 fs.BeginRead, fs.EndRead, fileData, 0, fileData.Length, null)
                 .ContinueWith((antecedent) =>
                     {
                         fs.Close();

                         // If we did not receive the entire file, the end of the 
                         // data buffer will contain garbage. 
                         if (antecedent.Result < fileData.Length)
                             Array.Resize(ref fileData, antecedent.Result);

                         // Will be returned in the Result property of the Task<string> 
                         // at some future point after the asynchronous file I/O operation completes. 
                         return new UTF8Encoding().GetString(fileData);
                     });
    }

    // Wait for all tasks to complete.  
    return Task<string>.Factory.ContinueWhenAll(tasks, (data) =>
    {
        // Propagate all exceptions and mark all faulted tasks as observed.
        Task.WaitAll(data);

        // Combine the results from all tasks.
        StringBuilder sb = new StringBuilder();
        foreach (var t in data)
        {
            sb.Append(t.Result);
        }
        // Final result to be returned eventually on the calling thread. 
        return sb.ToString();
    });

}

For those few cases in which the Begin method requires more than three input parameters, or has ref or out parameters, you can use the FromAsync overloads, for example, TaskFactory<TResult>.FromAsync(IAsyncResult, Func<IAsyncResult, TResult>), that represent only the End method. These methods can also be used in any scenario in which you are passed an IAsyncResult and want to encapsulate it in a Task.

static Task<String> ReturnTaskFromAsyncResult()
{
    IAsyncResult ar = DoSomethingAsynchronously();
    Task<String> t = Task<string>.Factory.FromAsync(ar, _ =>
        {
            return (string)ar.AsyncState;
        });

    return t;
}

The task returned by a FromAsync method has a status of WaitingForActivation and will be started by the system at some point after the task is created. If you attempt to call Start on such a task, an exception will be raised.

You cannot cancel a FromAsync task, because the underlying .NET Framework APIs currently do not support in-progress cancellation of file or network I/O. You can add cancellation functionality to a method that encapsulates a FromAsync call, but you can only respond to the cancellation before FromAsync is called or after it completed (for example, in a continuation task).

Some classes that support EAP, for example, WebClient, do support cancellation, and you can integrate that native cancellation functionality by using cancellation tokens.

The TPL does not provide any methods that are specifically designed to encapsulate an event-based asynchronous operation in the same way that the FromAsync family of methods wrap the IAsyncResult pattern. However, the TPL does provide the System.Threading.Tasks.TaskCompletionSource<TResult> class, which can be used to represent any arbitrary set of operations as a Task<TResult>. The operations may be synchronous or asynchronous, and may be I/O bound or compute-bound, or both.

The following example shows how to use a TaskCompletionSource<TResult> to expose a set of asynchronous WebClient operations to client code as a basic Task<TResult>. The method lets you enter an array of Web URLs, and a term or name to search for, and then returns the number of times the search term occurs on each site.

Task<string[]> GetWordCountsSimplified(string[] urls, string name, CancellationToken token)
{
    TaskCompletionSource<string[]> tcs = new TaskCompletionSource<string[]>();
    WebClient[] webClients = new WebClient[urls.Length];
    object m_lock = new object();
    int count = 0;
    List<string> results = new List<string>();

    // If the user cancels the CancellationToken, then we can use the 
    // WebClient's ability to cancel its own async operations.
    token.Register(() =>
    {
        foreach (var wc in webClients)
        {
            if (wc != null)
                wc.CancelAsync();
        }
    });


    for (int i = 0; i < urls.Length; i++)
    {
        webClients[i] = new WebClient();

        #region callback
        // Specify the callback for the DownloadStringCompleted 
        // event that will be raised by this WebClient instance.
        webClients[i].DownloadStringCompleted += (obj, args) =>
        {

            // Argument validation and exception handling omitted for brevity. 

            // Split the string into an array of words, 
            // then count the number of elements that match 
            // the search term. 
            string[] words = args.Result.Split(' ');
            string NAME = name.ToUpper();
            int nameCount = (from word in words.AsParallel()
                             where word.ToUpper().Contains(NAME)
                             select word)
                            .Count();

            // Associate the results with the url, and add new string to the array that  
            // the underlying Task object will return in its Result property.
            results.Add(String.Format("{0} has {1} instances of {2}", args.UserState, nameCount, name));

            // If this is the last async operation to complete, 
            // then set the Result property on the underlying Task. 
            lock (m_lock)
            {
                count++;
                if (count == urls.Length)
                {
                    tcs.TrySetResult(results.ToArray());
                }
            }
        };
        #endregion

        // Call DownloadStringAsync for each URL.
        Uri address = null;
        address = new Uri(urls[i]);
        webClients[i].DownloadStringAsync(address, address);

    } // end for 

    // Return the underlying Task. The client code 
    // waits on the Result property, and handles exceptions 
    // in the try-catch block there. 
    return tcs.Task;
}

For a more complete example, which includes additional exception handling and shows how to call the method from client code, see How to: Wrap EAP Patterns in a Task.

Remember that any task that is created by a TaskCompletionSource<TResult> will be started by that TaskCompletionSource and, therefore, user code should not call the Start method on that task.

In some scenarios, it may be desirable to directly expose the IAsyncResult pattern by using Begin/End method pairs in an API. For example, you may want to maintain consistency with existing APIs, or you may have automated tools that require this pattern. In such cases, you can use Tasks to simplify how the APM pattern is implemented internally.

The following example shows how to use tasks to implement an APM Begin/End method pair for a long-running compute-bound method.

class Calculator
{
    public IAsyncResult BeginCalculate(int decimalPlaces, AsyncCallback ac, object state)
    {
        Console.WriteLine("Calling BeginCalculate on thread {0}", Thread.CurrentThread.ManagedThreadId);
        Task<string> f = Task<string>.Factory.StartNew(_ => Compute(decimalPlaces), state);
        if (ac != null) f.ContinueWith((res) => ac(f));
        return f;
    }

    public string Compute(int numPlaces)
    {
        Console.WriteLine("Calling compute on thread {0}", Thread.CurrentThread.ManagedThreadId);

        // Simulating some heavy work.
        Thread.SpinWait(500000000);

        // Actual implemenation left as exercise for the reader. 
        // Several examples are available on the Web. 
        return "3.14159265358979323846264338327950288";
    }

    public string EndCalculate(IAsyncResult ar)
    {
        Console.WriteLine("Calling EndCalculate on thread {0}", Thread.CurrentThread.ManagedThreadId);
        return ((Task<string>)ar).Result;
    }
}

public class CalculatorClient
{
    static int decimalPlaces = 12;
    public static void Main()
    {
        Calculator calc = new Calculator();
        int places = 35;

        AsyncCallback callBack = new AsyncCallback(PrintResult);
        IAsyncResult ar = calc.BeginCalculate(places, callBack, calc);

        // Do some work on this thread while the calulator is busy.
        Console.WriteLine("Working...");
        Thread.SpinWait(500000);
        Console.ReadLine();
    }

    public static void PrintResult(IAsyncResult result)
    {
        Calculator c = (Calculator)result.AsyncState;
        string piString = c.EndCalculate(result);
        Console.WriteLine("Calling PrintResult on thread {0}; result = {1}",
                    Thread.CurrentThread.ManagedThreadId, piString);
    }
}

The Streamextensions.cs file, in Samples for Parallel Programming with the .NET Framework 4 on the MSDN Web site, contains several reference implementations that use Task objects for asynchronous file and network I/O.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.