在過去幾年間，多線程編程已經成為了一個熱門話題。雖然我們長久以來一直都希望能有高速響應的用戶界面，但實現這個愿望的工具卻遲遲不見蹤跡。對于大多數框架（包括.NET程序員所使用的那些框架）來說，對用戶界面的更新仍然局限于單獨一個線程，同時，硬件制造商已經轉向了多核來代替更快的CPU。

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

　　如今的異步模式的一個大問題在于他們組合的不好。每個異步操作都需要通過回調鏈接到下一個。但回調是無法組合的，每一步都是獨立的函數，無法劃分到常見的編碼結構中，如循環、using或是try——catch塊。

　　結果，大多數開發者實際上并沒有使用異步模式。他們轉向了并發的多線程，依賴于后臺線程和手工同步。但這種方式也存在著問題。由于將線程浪費在了阻塞的I/O上，因此你失去了操作系統所提供的性能與可伸縮性的優勢，比如說I/O Completion Ports，更不必說調度大量線程給內存帶來的壓力了。此外，你還可以使用單獨一個線程和循環，這意味著每次I/O操作都得等到之前的操作完成后才能開始。

　　也就是說，我們按照這種方式編寫代碼已經有很長一段時間了，在大多數情況下都沒什么問題。通常，計算機都有足夠的速度和內存來處理對線程的草率使用，這使得將數據編排到UI線程變得不那么困難。那到底有什么變化呢？

　　有三件事：

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

　　其次是參與的人。與很多研究項目會雇傭畢業生不同，Somasegar打造了一個由5個天才項目經理所構成的團隊，他們負責構建語法，以此證明異步編程可以像同步編程一樣簡單。這些開發者是Avner Aharoni、Mads Torgersen、Stephen Toub、Alex Turner以及Lucian Wischik，他們都是.NET領域的名家。沒有他們的協作與奉獻，CTP是不可能出現的。

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

　　當然了，這可能意味著C#與VB應該支持異步語法。如果這在C# 5/VB 11中真的發生了，那么一旦發現語義不正確就沒機會再移除掉了。這需要以犧牲其他特性作為代價，從“編譯器即服務（compiler-as-a-service）”到各種細小的特性。

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

NET技術：微軟緣何認為VB與C#需要異步語法，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。