異步事件回調機制原理探索 (轉)

http://blog.csdn.net/blues1021/article/details/44276085

軟件組件之間，函數之間的調用分爲：同步調用，函數指針形式的同步回調，異步調用。前面兩種很簡單無需多言，這裏只探索下異步調用。

自定義的異步事件回調機制：

能夠在本身的應用程序中，先註冊事件和事件對應的回調函數(回調函數能夠是函數指針法，虛函數方法的方式);本身程序中每幀檢測事件是否發生或者條件是否知足，知足的時候就進入回調函數。若是這樣的檢查是在同一個線程中那麼就是同步的延遲調用，若是是在子線程中就是異步調用，可是這樣的性能仍是比較差的，除非不得以，不然仍是用OS的異步回調機制性能高。

OS層面的異步事件回調機制：

linux下的異步回調機制：

1.異步事件的註冊：會在內核裏面產生一個事件放置到事件隊列（屬於內核事件或者線程/進程事件隊列，加入事件select,poll是O(n)算法效率，epoll是O(1)算法效率由於使用了mmap不須要從用戶空間拷貝到內核空間，其它事件相似)；2.異步事件的檢測：檢查時候會查詢內核中的線程/進程事件隊列（select,poll是O(n)算法效率，epoll是O(1)算法效率應該使用了數組類型的數據結構存儲映射關係，其它事件相似 )；阻塞線程/進程若是存在知足事件那麼立刻返回結果，。 非阻塞的線程/進程條件知足返回結果，條件不知足那麼返回非阻塞的信息，能夠繼續作其它事情。

3.異步事件的回調驅動：文件設備驅動程序內有讀寫隊列，當讀寫隊列資源變爲可讀or寫的時候(進程繼續執行(或發出事件通知到內核事件隊列/線程進程的事件隊列中)。喚醒後會再次判斷文件設備條件是否知足由於非獨佔的資源可能被其它線程/進程獲取了； 阻塞條件下成功了立刻執行異步回調，返回中斷現場繼續執行程序邏輯，非阻塞條件下線程執行到此處檢查事件隊列將會成功從而產生異步調用，返回當時中斷現場執行條件知足的後續邏輯，unity3d的coroutine也是這樣的原理。

回調事件註冊和異步事件的驅動都和linux下相似。

只 是檢查異步事件的消息, windows內核有一個事件隊列，內核也爲當前的用戶線程建立事件隊列，當內核驅動觸發事件（週期觸發或OS通知觸發)時，消息會被分發到內核事件隊 列，分發到當前線程事件隊列；當前線程須要一個消息循環不斷的獲取消息,固然也提供了阻塞模式和非阻塞模式的檢測消息(getmessage沒有得到去到 消息會阻塞掛起當前線程，peekmessage沒有獲取到消息返回FALSE不會阻塞掛起當前線程)，接收到了消息要進行分發處理。

如圖：

爲了更清楚地說明這個問題，咱們參看圖1：

 

 

==================

http://www.cnblogs.com/DebugLZQ/archive/2012/09/05/2670986.html

最近很忙，所以拿出時間來寫博客也算是忙裏偷閒了，繼承前面的一向風格，繼續淺談胡侃。
　　最近在項目中遇到了Socket異步網絡傳輸 的問題，因此沉下心來整理下。因而，先問了下度娘，結果找到了園友志良的一篇文章《C#中異步和多線程的區別》（參考文獻1），精讀了一遍，我的以爲理解 的很好，本身學習下之餘，又動手加工了一下以分享給各位博友，但願各位博友能對異步和多線程有一個清楚的認識。

　　C#中異步和多線程的區別是什麼呢？異步和多線程二者均可以達到避免調用線程阻塞的目的，從而提升軟件的可響應性。甚至有些時候咱們就認爲異步和多線程是等同的概念。可是，異步和多線程仍是有一些區別的。而這些區別形成了使用異步和多線程的時機的區別。　　

　　異步操做的本質

　　全部的程序最終都會由計算機硬件來執行，因此爲了更好的理解異步 操做的本質，咱們有必要了解一下它的硬件基礎。 熟悉電腦硬件的朋友確定對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操做。這樣在只有少數幾個併發操做的時候還無傷大雅，若是須要處理大量的併發操做時就不合適了。

　　異步的一個示例

　　你們可能都知道，使用delegate能夠「自動」使一個方法能夠進行異步的調用。從直覺上來講，我以爲是由編譯器或者CLR使用了另外的線程來執行目標方法。究竟是不是這樣呢？