.NET异步编程模型：TAP、EAP与APM对比

需积分: 9 26 浏览量更新于2024-07-19 收藏 927KB PDF 举报

"异步编程是.NET框架中的重要概念，它提供了三种异步操作模式：Asynchronous Programming Model（APM）、Event-based Asynchronous Pattern（EAP）以及Task-based Asynchronous Pattern（TAP）。这些模式帮助开发者在不影响主线程的情况下执行耗时操作，提高应用的响应性和用户体验。下面将详细介绍这三种模式。 Task-based Asynchronous Pattern (TAP) 是.NET 4.0引入的一种新模型，基于`Task`和`async/await`关键字。实现TAP的关键在于定义一个返回`Task`或`Task<T>`的方法，利用`async`关键字标记方法，并在其中使用`await`来处理异步操作。这样可以简化异步代码，使其更接近同步代码的阅读体验。消费者可以通过调用`await`方法来等待任务完成，无需处理回调或管理状态对象。 Consuming the Task-based Asynchronous Pattern: 消费者可以非常直观地使用`await`关键字等待任务完成，如果任务已经完成，`await`会立即返回结果；如果任务未完成，它会将控制权交还给调用者，直到任务完成后再恢复执行。这使得代码的逻辑更清晰，异常处理也更加简单。 Interop with Other Asynchronous Patterns and Types: TAP与其他异步模式有很好的互操作性，可以方便地转换或调用EAP、APM模式的方法，或者与`IAsyncResult`接口配合使用。 Event-based Asynchronous Pattern (EAP) 是基于事件的异步模式，适用于UI应用程序，允许用户界面在后台操作执行时保持响应。EAP通过提供开始异步操作的方法（如`BeginXXX`）和结束异步操作的方法（如`EndXXX`），以及一个或多个事件（如`Completed`事件）来实现。多线程编程时，EAP可以避免阻塞主线程，但它的代码通常比TAP更复杂，错误处理也更困难。 Multithreaded Programming with the Event-based Asynchronous Pattern: EAP方法通常在后台线程上执行，当操作完成后，通过引发事件通知主线程。开发者需要确保在正确的线程上下文中处理事件，以避免UI更新问题。 Asynchronous Programming Model (APM) pattern，也被称为“Begin/End”模式，是最早的异步编程模式之一。它通过`IAsyncResult`接口进行异步操作，需要开发者手动管理和调度线程。APM模式通常涉及到`BeginXXX`和`EndXXX`方法，`BeginXXX`启动异步操作并立即返回，`EndXXX`用于获取操作的结果。 Calling Asynchronous Methods Using IAsyncResult: 在APM模式下，`BeginXXX`方法的返回值是`IAsyncResult`实例，它包含了关于异步操作的状态信息。开发者需要保存这个结果以便稍后调用`EndXXX`来结束操作。 Asynchronous Programming Using Delegates: APM模式常常与委托结合使用，委托可以作为回调函数，当异步操作完成时被调用。这种方式增加了代码的复杂性，但在.NET早期版本中是实现异步操作的常见方式。 TAP是目前推荐的异步编程模式，因为它提供了更好的可读性和易用性，而EAP和APM则在特定场景下仍有一定应用。了解并熟练掌握这三种模式，对于.NET开发者来说至关重要，能够更好地应对各种异步编程挑战。"

public async Task<Bitmap> DownloadDataAndRenderImageAsync(

CancellationToken cancellationToken)

{

var imageData = await DownloadImageDataAsync(cancellationToken);

return await RenderAsync(imageData, cancellationToken);

}

Public Async Function DownloadDataAndRenderImageAsync(

cancellationToken As CancellationToken) As Task(Of Bitmap)

Dim imageData As ImageData = Await DownloadImageDataAsync(cancellationToken)

Return Await RenderAsync(imageData, cancellationToken)

End Function

See also

This example also demonstrates how a single cancellation token may be threaded through multiple asynchronous

operations. For more information, see the cancellation usage section in Consuming the Task-based Asynchronous

Pattern.

Task-based Asynchronous Pattern (TAP)

Consuming the Task-based Asynchronous Pattern

Interop with Other Asynchronous Patterns and Types

Consuming the Task
-
based Asynchronous Pattern
11/21/2017 • 22 min to read • Edit Online
Suspending Execution with Await
Configuring Suspension and Resumption with Yield and ConfigureAwaitConfiguring Suspension and Resumption with Yield and ConfigureAwait
When you use the Task-based Asynchronous Pattern (TAP) to work with asynchronous operations, you can use
callbacks to achieve waiting without blocking. For tasks, this is achieved through methods such as
Task.ContinueWith. Language-based asynchronous support hides callbacks by allowing asynchronous operations
to be awaited within normal control flow, and compiler-generated code provides this same API-level support.
Starting with the .NET Framework 4.5, you can use the await keyword in C# and the Await Operator in Visual Basic
to asynchronously await Task and Task<TResult> objects. When you're awaiting a Task, the  await  expression is
of type  void . When you're awaiting a Task<TResult>, the  await  expression is of type  TResult . An  await
expression must occur inside the body of an asynchronous method. For more information about C# and Visual
Basic language support in the .NET Framework 4.5, see the C# and Visual Basic language specifications.
Under the covers, the await functionality installs a callback on the task by using a continuation. This callback
resumes the asynchronous method at the point of suspension. When the asynchronous method is resumed, if the
awaited operation completed successfully and was a Task<TResult>, its  TResult  is returned. If the Task or
Task<TResult> that was awaited ended in the Canceled state, an OperationCanceledException exception is thrown.
If the Task or Task<TResult> that was awaited ended in the Faulted state, the exception that caused it to fault is
thrown. A  Task  can fault as a result of multiple exceptions, but only one of these exceptions is propagated.
However, the Task.Exception property returns an AggregateException exception that contains all the errors.
If a synchronization context (SynchronizationContext object) is associated with the thread that was executing the
asynchronous method at the time of suspension (for example, if the SynchronizationContext.Current property is
not  null ), the asynchronous method resumes on that same synchronization context by using the context’s Post
method. Otherwise, it relies on the task scheduler (TaskScheduler object) that was current at the time of
suspension. Typically, this is the default task scheduler (TaskScheduler.Default), which targets the thread pool. This
task scheduler determines whether the awaited asynchronous operation should resume where it completed or
whether the resumption should be scheduled. The default scheduler typically allows the continuation to run on the
thread that the awaited operation completed.
When an asynchronous method is called, it synchronously executes the body of the function up until the first
await expression on an awaitable instance that has not yet completed, at which point the invocation returns to the
caller. If the asynchronous method does not return  void , a Task or Task<TResult> object is returned to represent
the ongoing computation. In a non-void asynchronous method, if a return statement is encountered or the end of
the method body is reached, the task is completed in the RanToCompletion final state. If an unhandled exception
causes control to leave the body of the asynchronous method, the task ends in the Faulted state. If that exception
is an OperationCanceledException, the task instead ends in the Canceled state. In this manner, the result or
exception is eventually published.
There are several important variations of this behavior. For performance reasons, if a task has already completed
by the time the task is awaited, control is not yielded, and the function continues to execute. Additionally, returning
to the original context isn't always the desired behavior and can be changed; this is described in more detail in the
next section.
Several methods provide more control over an asynchronous method’s execution. For example, you can use the
Task.Yield method to introduce a yield point into the asynchronous method:

public class Task : …

{

public static YieldAwaitable Yield();

…

}

Task.Run(async delegate

{

for(int i=0; i<1000000; i++)

{

await Task.Yield(); // fork the continuation into a separate work item

...

}

});

await someTask.ConfigureAwait(continueOnCapturedContext:false);

Canceling an Asynchronous Operation

var cts = new CancellationTokenSource();

string result = await DownloadStringAsync(url, cts.Token);

… // at some point later, potentially on another thread

cts.Cancel();

var cts = new CancellationTokenSource();

IList<string> results = await Task.WhenAll(from url in urls select DownloadStringAsync(url, cts.Token));

// at some point later, potentially on another thread

…

cts.Cancel();

This is equivalent to asynchronously posting or scheduling back to the current context.

You can also use the Task.ConfigureAwait method for better control over suspension and resumption in an

asynchronous method. As mentioned previously, by default, the current context is captured at the time an

asynchronous method is suspended, and that captured context is used to invoke the asynchronous method’s

continuation upon resumption. In many cases, this is the exact behavior you want. In other cases, you may not

care about the continuation context, and you can achieve better performance by avoiding such posts back to the

original context. To enable this, use the Task.ConfigureAwait method to inform the await operation not to capture

and resume on the context, but to continue execution wherever the asynchronous operation that was being

awaited completed:

Starting with the .NET Framework 4, TAP methods that support cancellation provide at least one overload that

accepts a cancellation token (CancellationToken object).

A cancellation token is created through a cancellation token source (CancellationTokenSource object). The source’s

Token property returns the cancellation token that will be signaled when the source’s Cancel method is called. For

example, if you want to download a single webpage and you want to be able to cancel the operation, you create a

CancellationTokenSource object, pass its token to the TAP method, and then call the source’s Cancel method when

you're ready to cancel the operation:

To cancel multiple asynchronous invocations, you can pass the same token to all invocations:

Or, you can pass the same token to a selective subset of operations:

var cts = new CancellationTokenSource();

byte [] data = await DownloadDataAsync(url, cts.Token);

await SaveToDiskAsync(outputPath, data, CancellationToken.None);

… // at some point later, potentially on another thread

cts.Cancel();

Monitoring Progress

private async void btnDownload_Click(object sender, RoutedEventArgs e)

{

btnDownload.IsEnabled = false;

try

{

txtResult.Text = await DownloadStringAsync(txtUrl.Text,

new Progress<int>(p => pbDownloadProgress.Value = p));

}

finally { btnDownload.IsEnabled = true; }

}

Using the Built

in Task

based Combinators

Task.RunTask.Run

Cancellation requests may be initiated from any thread.

You can pass the CancellationToken.None value to any method that accepts a cancellation token to indicate that

cancellation will never be requested. This causes the CancellationToken.CanBeCanceled property to return false ,

and the called method can optimize accordingly. For testing purposes, you can also pass in a pre-canceled

cancellation token that is instantiated by using the constructor that accepts a Boolean value to indicate whether

the token should start in an already-canceled or not-cancelable state.

This approach to cancellation has several advantages:

You can pass the same cancellation token to any number of asynchronous and synchronous operations.

The same cancellation request may be proliferated to any number of listeners.

The developer of the asynchronous API is in complete control of whether cancellation may be requested

and when it may take effect.

The code that consumes the API may selectively determine the asynchronous invocations that cancellation

requests will be propagated to.

Some asynchronous methods expose progress through a progress interface passed into the asynchronous

method. For example, consider a function which asynchronously downloads a string of text, and along the way

raises progress updates that include the percentage of the download that has completed thus far. Such a method

could be consumed in a Windows Presentation Foundation (WPF) application as follows:

The System.Threading.Tasks namespace includes several methods for composing and working with tasks.

The Task class includes several Run methods that let you easily offload work as a Task or Task<TResult> to the

thread pool, for example:

public async void button1_Click(object sender, EventArgs e)

{

textBox1.Text = await Task.Run(() =>

{

// … do compute-bound work here

return answer;

});

}

public async void button1_Click(object sender, EventArgs e)

{

pictureBox1.Image = await Task.Run(async() =>

{

using(Bitmap bmp1 = await DownloadFirstImageAsync())

using(Bitmap bmp2 = await DownloadSecondImageAsync())

return Mashup(bmp1, bmp2);

});

}

Task.FromResultTask.FromResult

public Task<int> GetValueAsync(string key)

{

int cachedValue;

return TryGetCachedValue(out cachedValue) ?

Task.FromResult(cachedValue) :

GetValueAsyncInternal();

}

private async Task<int> GetValueAsyncInternal(string key)

{

…

}

Task.WhenAllTask.WhenAll

IEnumerable<Task> asyncOps = from addr in addrs select SendMailAsync(addr);

await Task.WhenAll(asyncOps);

Some of these Run methods, such as the Task.Run(Func<Task>) overload, exist as shorthand for the

TaskFactory.StartNew method. Other overloads, such as Task.Run(Func<Task>), enable you to use await within

the offloaded work, for example:

Such overloads are logically equivalent to using the TaskFactory.StartNew method in conjunction with the Unwrap

extension method in the Task Parallel Library.

Use the FromResult method in scenarios where data may already be available and just needs to be returned from

a task-returning method lifted into a Task<TResult>:

Use the WhenAll method to asynchronously wait on multiple asynchronous operations that are represented as

tasks. The method has multiple overloads that support a set of non-generic tasks or a non-uniform set of generic

tasks (for example, asynchronously waiting for multiple void-returning operations, or asynchronously waiting for

multiple value-returning methods where each value may have a different type) and to support a uniform set of

generic tasks (such as asynchronously waiting for multiple TResult -returning methods).

Let's say you want to send email messages to several customers. You can overlap sending the messages so you're

not waiting for one message to complete before sending the next. You can also find out when the send operations

have completed and whether any errors have occurred:

剩余172页未读，继续阅读

luanzhiye

粉丝: 1
资源: 18

.NET异步编程模型：TAP、EAP与APM对比

Pro Asynchronous Programming with .NET

asp.net异步刷新案例

.NET异步编程模型：APM、EAP与TAP对比分析

Combine Asynchronous Programming with Swift (Combine异步编程指南): PDF+EPUB+源码

Programming ASP.NET

【用户体验提升】ASP.NET异步编程：5大实践优化交互体验

ASP.NET中的异步编程模型

ASP.NET异步调用

asp.net 异步分页

ajax.net异步调用

最新资源