.NET Framework
在CPU進入多核心時代後，原本只限應用於高階多CPU電腦的平行運算技術，也因為多核心的平價化而逐漸浮現在家用電腦應用，什麼是平行運算呢？說穿了其實很簡單，就是依據CPU所內含的核心數，建立對應數量的執行緒，此時CPU的效能會發揮到極致，以2核心CPU為例，
圖18中有三個角色，Task Factory負責建立Task物件，Task Scheduler則負責Task的排程事宜。讀者們會覺得很奇怪，至今為止，我們建立Task的方式都是直接以new方式建立，其中並未見到Task Factory的蹤影呀？是的！這是因為Task類別的建構子預設會使用系統所產生的Task Factory物件，所以不需要設計師特別的傳入Task Factory或是明確的使用Task Factory來建立Task，以下是Task類別的模擬碼。
Task Library除了支援Planed/Un plan Exit時的例外處理，及Local Queue、Working Stealing機制外，還有一項很有趣的機制，那就是Continue With機制，這個機制允許設計師在一個執行緒結束後，緊接著安排另一個執行緒來執行指定的delegate，以較簡單、白話的說，就是執行緒的流程控管機制。
Thread Pool的出現，減輕了撰寫多執行緒應用程式時，所需承擔的執行緒過多而導致效能低落的風險，同時也透過重用執行緒來節省建立執行緒的時間，但是Thread Pool原始的設計仍然是太陽春了點，如前面所展示的，當我們需要等待多個Threads結束才做下一件事時，要嘛就使用Wait Handle在主程式等，要嘛就另外開一個執行緒，於內使用Wait Handle來等待，前者會造成主程式的停滯，後者則會多使用一個執行緒，雖然還是有辦法來調整至完美，但還是需要一道手續。
越是資深的程式設計師，對於運用到 Multi-Threading (多執行緒)的程式就越加謹慎，深怕一不小心就會埋下難以查覺的 BUG ，使用多執行緒就像是面對數匹脫疆野馬，一旦牠們開始跑後，你就很難控制牠們的走向，有些會順利到達終點，有些則會在途中出現意外。
當閱讀了dynamic型別有關的C# 4.0白皮書時，我很自然的想到了TDD(Test Diven Development)，TDD原本意圖讓設計師在撰寫真正程式碼前撰寫測試碼，這個立意很好，因為大多數的設計師總是在完成程式後再來考慮撰寫測試碼，結果是測試碼永遠跟不上真正的程式碼，被放棄的機率高的嚇人。
看著一個程式語言的誕生，然後逐步追隨其成長，是一件相當有趣的事，特別是該程式語言一直都處於主流語言的時候，很可惜的，這種機會並不常有，C#是在我程式生涯中，唯一一個從其出生即跟隨至今的程式語言。在C#誕生之初，也是Anders Hejlsberg離開Borland之後的數年後
如標題,ADO.NET Entity Framework 的最終版本也包含在SP1中了.
摘要:DataSource Control 之Cache機制
摘要:DataSource Control 與 Transaction的課題
Full .NET Framework Archive