07 2008 檔案

摘要：雖然我們整篇都在討論.NET下的Multi-threading的問題，但是實際上很多問題都是可以類推的。例如前幾次我們反復的說道了關于CriticalSection的問題。說它比MUTEX有何優越之處，例如速度就是一個明顯的優勢。但是從留言中發現在這個問題上存在著一些誤會。今天不妨就閑扯一下這個問題。 閱讀全文

摘要：話說看了Angel Lucifer兄的留言之后，發現果然Microsoft在June CTP中實現了SemaphoreSlim，其中不但考慮了與舊的同步對象在接口上的一致性，還加入了Cancellation的檢查。唉，怪我沒有跟上形勢！那么這篇就成班門弄斧了。不過，還應該堅持把它寫完，善始善終，就當為大家整理思路。取笑罷了:-) 閱讀全文

摘要：信號量歷史悠久，折磨死了一代又一代的計算機專業學生，但是不得不承認其在Multi-thread環境下的巨大作用。最經典的案例莫過于管理一個環狀緩沖區。.NET 中的Semaphore對象等同于Win32中的Semaphore。屬于內核級對象，因此使用它的代價就比較大了。并且Semaphore對象每次僅僅能夠等待一個Count，這有的時候讓事情變得有些煩，例如你可能不得不將環狀緩沖區分割為一個個的Chunk（實際上這是一個好方法，因為我們應該對于Cache進行優化）。Qt中的信號量可以一次獲得多個Count，感覺很方便。綜上，我們希望自己動手實現一個輕量級的，支持一次獲得多個資源的信號量。 閱讀全文

摘要：多核處理，并行設計已經成為了計算機發展不可阻擋的趨勢之一。越來越多的技術人員開始關注多線程程序設計。但是選擇什么樣的環境來介入多線程程序設計往往是一個比較頭疼的問題。應該說，目前的許多環境并沒有為多線程建立良好的模型，例如C和C++。為此，人們試圖在這種環境中通過添加庫的方式為其加入多線程的功能。但是，這顯然是不合適的，實際上許多的時候，程序庫根本不能解決所有的問題，我們真正需要的是一種將多線程納入其規范體系之內的環境。 閱讀全文

摘要：上一篇隨筆“"Loads are not reorderd with other loads" is a FACT!! 續：不要指望 volatile”中已經提到了。.NET的內存模型在volatile load上的實現是錯誤的。這在今天終于是半個官方的結論了。有關這個討論的結論可以參考“A bit more formalism as to why CLR's MM is broken on x86/x64 ”。關于內存模型（MM）的問題枯燥，縮略詞跟別的領域有過之無不及，為了便于說明趁著這個機會羅列一下。 閱讀全文

摘要：上一篇隨筆中提到了volatile，實際上由于上一篇中提到的問題，volatile已經越來越遠離其應有的含義了。在說這個問題之前，我們又要提.NET的內存模型問題（以下簡稱MM），我不指望在這里長篇大論的說其內存模型是如何的。簡單的說就是以下的幾句話... 閱讀全文

摘要：對于多線程編程的難度，再充分的心里準備也許都是不夠的。前一段時間一直在整理一些有關多線程編程的內容（一個對多線程算法庫編寫過程中的經驗積累）。而在前天，一篇來自于Microsoft 的PFX的Joe的博文驚現："Loads cannot pass other loads" is a ~myth ，著實讓人驚出了一身冷汗。 閱讀全文