在過(guò)去幾年間，多線程編程已經(jīng)成為了一個(gè)熱門(mén)話題。雖然我們長(zhǎng)久以來(lái)一直都希望能有高速響應(yīng)的用戶界面，但實(shí)現(xiàn)這個(gè)愿望的工具卻遲遲不見(jiàn)蹤跡。對(duì)于大多數(shù)框架（包括.NET程序員所使用的那些框架）來(lái)說(shuō)，對(duì)用戶界面的更新仍然局限于單獨(dú)一個(gè)線程，同時(shí)，硬件制造商已經(jīng)轉(zhuǎn)向了多核來(lái)代替更快的CPU。

　　C#與VB一開(kāi)始提供了非常簡(jiǎn)單的并發(fā)支持，這是通過(guò)對(duì)監(jiān)視器與委托使用lock/SyncLock關(guān)鍵字來(lái)實(shí)現(xiàn)的，異步程序庫(kù)通過(guò)這兩個(gè)關(guān)鍵字實(shí)現(xiàn)異步編程。在隨后的幾個(gè)版本中，我們并沒(méi)有看到這兩種語(yǔ)言在異步領(lǐng)域有任何進(jìn)展，微軟的精力都放在其他領(lǐng)域上了。隨著.NET 4.0的到來(lái)，情況有了很大的變化。.NET 4.0引入了3個(gè)新的程序庫(kù)：Task Parallel Library（TPL）、Parallel LINQ以及Coordination Data Structures（CDS）。這些程序庫(kù)構(gòu)建在增強(qiáng)的語(yǔ)法之上，如lambda、closure以及LINQ，極大簡(jiǎn)化了多線程開(kāi)發(fā)工作。但這些庫(kù)也不是十全十美的。Parallel LINQ看起來(lái)沒(méi)什么問(wèn)題，而對(duì)TPL的異步調(diào)用依舊充滿了壞味道，有時(shí)還會(huì)出錯(cuò)。

　　如今的異步模式的一個(gè)大問(wèn)題在于他們組合的不好。每個(gè)異步操作都需要通過(guò)回調(diào)鏈接到下一個(gè)。但回調(diào)是無(wú)法組合的，每一步都是獨(dú)立的函數(shù)，無(wú)法劃分到常見(jiàn)的編碼結(jié)構(gòu)中，如循環(huán)、using或是try——catch塊。

　　結(jié)果，大多數(shù)開(kāi)發(fā)者實(shí)際上并沒(méi)有使用異步模式。他們轉(zhuǎn)向了并發(fā)的多線程，依賴于后臺(tái)線程和手工同步。但這種方式也存在著問(wèn)題。由于將線程浪費(fèi)在了阻塞的I/O上，因此你失去了操作系統(tǒng)所提供的性能與可伸縮性的優(yōu)勢(shì)，比如說(shuō)I/O Completion Ports，更不必說(shuō)調(diào)度大量線程給內(nèi)存帶來(lái)的壓力了。此外，你還可以使用單獨(dú)一個(gè)線程和循環(huán)，這意味著每次I/O操作都得等到之前的操作完成后才能開(kāi)始。

　　也就是說(shuō)，我們按照這種方式編寫(xiě)代碼已經(jīng)有很長(zhǎng)一段時(shí)間了，在大多數(shù)情況下都沒(méi)什么問(wèn)題。通常，計(jì)算機(jī)都有足夠的速度和內(nèi)存來(lái)處理對(duì)線程的草率使用，這使得將數(shù)據(jù)編排到UI線程變得不那么困難。那到底有什么變化呢？

　　有三件事：

　　首先是基礎(chǔ)項(xiàng)目。Async CTP并非憑空出現(xiàn)的，它構(gòu)建在之前的大量研究與產(chǎn)品項(xiàng)目基礎(chǔ)之上。這包括了異步語(yǔ)言Axum、Task Parallel Library（TPL）、Reactive Extensions（Rx）以及F#的異步工作流。當(dāng)這些工作全部完成后，VB/C#中的異步語(yǔ)法將成為下一步工作。

　　其次是參與的人。與很多研究項(xiàng)目會(huì)雇傭畢業(yè)生不同，Somasegar打造了一個(gè)由5個(gè)天才項(xiàng)目經(jīng)理所構(gòu)成的團(tuán)隊(duì)，他們負(fù)責(zé)構(gòu)建語(yǔ)法，以此證明異步編程可以像同步編程一樣簡(jiǎn)單。這些開(kāi)發(fā)者是Avner Aharoni、Mads Torgersen、Stephen Toub、Alex Turner以及Lucian Wischik，他們都是.NET領(lǐng)域的名家。沒(méi)有他們的協(xié)作與奉獻(xiàn)，CTP是不可能出現(xiàn)的。

　　最后是Silverlight。除了是Flash的替代者以外，Silverlight還是微軟移動(dòng)戰(zhàn)略中的重要棋子。除非開(kāi)發(fā)游戲，否則不使用Silverlight是沒(méi)法在Windows Phone 7上編寫(xiě)應(yīng)用的。Sivlerlight并不支持異步的I/O操作。曾嘗試將WPF代碼移植到Silverlight上的開(kāi)發(fā)者知道，Sivlerlight是不支持異步I/O操作的。你別無(wú)選擇，只能使用異步模式。Lucian在其“Async CTP簡(jiǎn)介”一文中闡釋了這么做是多么的復(fù)雜。

　　當(dāng)然了，這可能意味著C#與VB應(yīng)該支持異步語(yǔ)法。如果這在C# 5/VB 11中真的發(fā)生了，那么一旦發(fā)現(xiàn)語(yǔ)義不正確就沒(méi)機(jī)會(huì)再移除掉了。這需要以犧牲其他特性作為代價(jià)，從“編譯器即服務(wù)（compiler-as-a-service）”到各種細(xì)小的特性。

　　查看英文原文：Why Microsoft Believes that VB and C# Need an Asynchronous Syntax

NET技術(shù)：微軟緣何認(rèn)為VB與C#需要異步語(yǔ)法，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。