[ZT]异步调用与多线程的区别

随着拥有多个硬线程CPU（超线程、双核）的普及，多线程和异步操作等并发程序设计方法也受到了更多的关注和讨论。本文主要是想与园中各位高手一同探讨一下如何使用并发来最大化程序的性能。

　　多线程和异步操作的异同

　　多线程和异步操作两者都可以达到避免调用线程阻塞的目的，从而提高软件的可响应性。甚至有些时候我们就认为多线程和异步操作是等同的概念。但是，多线程和异步操作还是有一些区别的。而这些区别造成了使用多线程和异步操作的时机的区别。

　　异步操作的本质

　 　所有的程序最终都会由计算机硬件来执行，所以为了更好的理解异步操作的本质，我们有必要了解一下它的硬件基础。 熟悉电脑硬件的朋友肯定对DMA这个词不陌生，硬盘、光驱的技术规格中都有明确DMA的模式指标，其实网卡、声卡、显卡也是有DMA功能的。DMA就是直 接内存访问的意思，也就是说，拥有DMA功能的硬件在和内存进行数据交换的时候可以不消耗CPU资源。只要CPU在发起数据传输时发送一个指令，硬件就开 始自己和内存交换数据，在传输完成之后硬件会触发一个中断来通知操作完成。这些无须消耗CPU时间的I/O操作正是异步操作的硬件基础。所以即使在DOS 这样的单进程（而且无线程概念）系统中也同样可以发起异步的DMA操作。

　　线程的本质

　　线程不是一个计算机硬件的功能，而是操作系统提供的一种逻辑功能，线程本质上是进程中一段并发运行的代码，所以线程需要操作系统投入CPU资源来运行和调度。

　　异步操作的优缺点

　 　因为异步操作无须额外的线程负担，并且使用回调的方式进行处理，在设计良好的情况下，处理函数可以不必使用共享变量（即使无法完全不用，最起码可以减少 共享变量的数量），减少了死锁的可能。当然异步操作也并非完美无暇。编写异步操作的复杂程度较高，程序主要使用回调方式进行处理，与普通人的思维方式有些 初入，而且难以调试。

　　多线程的优缺点

　　多线程的优点很明显，线程中的处理程序依然是顺序执行，符合普通人的思维习惯，所以编程简单。但是多线程的缺点也同样明显，线程的使用（滥用）会给系统带来上下文切换的额外负担。并且线程间的共享变量可能造成死锁的出现。

　　各自适用场合

　 　在了解了线程与异步操作各自的优缺点之后，我们可以来探讨一下线程和异步的合理用途。我认为：当需要执行I/O操作时，使用异步操作比使用线程+同步 I/O操作更合适。I/O操作不仅包括了直接的文件、网络的读写，还包括数据库操作、Web Service、HttpRequest以及.net Remoting等跨进程的调用。

　　而线程的适用范围则是那种需要长时间CPU运算的场合，例如耗时较长的图形处理和算法执行。但是往 往由于使用线程编程的简单和符合习惯，所以很多朋友往往会使用线程来执行耗时较长的I/O操作。这样在只有少数几个并发操作的时候还无伤大雅，如果需要处 理大量的并发操作时就不合适了。

 

 You need to examine the requirements of your application carefully to determine whether or not the code you're writing can even benefit from asynchronous events. Here are some general guidelines to consider when making your decision:

 

• Consider asynchronous processing if the calling thread controls a Windows user interface. In this case, the calling thread can't afford to be blocked during a remote method call because the UI will freeze.
• Asynchronous processing may help with scalability if the Web Services client is an ASP.NET application or another ASP.NET Web Service. In this scenario, a blocked synchronous call in the code can stall the ASP.NET worker thread, which can force other applications' requests to queue and, therefore, impact scalability. Using asynchronous communication instead could at least free up the threads that ASP.NET isn't using for the Web Service calls. Asynchronous server processing is discussed in detail towards the end of this chapter.
• If there is a possibility that the remote procedure call to the Web Service may take a while to complete, asynchronous processing may be beneficial. In this case the client application can do other work on the thread before it needs the results from the remote procedure call.
• The client application may need to make concurrent calls to one or more remote services. In this case, using an asynchronous remote procedure call is much better than spinning off multiple threads to do the same work. For example, if an application needs to make concurrent synchronous calls to three different Web Services, it cannot do so with one thread. It has to spin off at least two threads and make a remote call in each thread. However, if the client uses an asynchronous remote call, it can make all three calls on one thread and then wait for all of them.

 

 

 

The client-side asynchronous capabilities of a Web service are defined by the underlying development environment, in this case, .NET.  The WSDL toolkit (wsdl.exe) included with the .NET SDK generates two types of asynchronous methods: Begin\End and Async\Completed.  Both are completely valid and supported in .NET 2.0, 3.0, and 3.5.  Note, using “Add Web Reference” within Visual Studio 2005 will only generate the Async\Completed methods.  To construct both, use wsdl.exe on the command line.   

 

The Begin\End pattern has existed since .NET 1.1 and uses a callback technique for managing and tracking an asynchronous call.  The Async\Completed pattern was introduced in .NET 2.0 as an event-driven asynchronous model.    Both techniques initiate a call to the remote Web service on a threadpool thread.