• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            操作系統運行中,種有各種事情打斷和切換,通過系統陷阱來實現: 


            簡單來說就和應用層的回調函數一樣, 只不過這些處理是在操作系統內核里面,系統初始化時就填充好了IDT(interrupt dispatch table), 當中斷發生時, 系統會根據中斷類型,去調用對應的ISR(interrupt service routine). 當中斷發生時,操作系統內核會保存足夠多的信息(陷阱幀), 這樣系統處理完中斷之后可以回到原來的地方繼續執行。看起來好像和我們應用層的函數調用一樣, 但是他們的實現是完全不同的, 函數調用是同一線程, 通過堆棧來實現的;中斷處理涉及到線程切換,要保存線程的執行環境。


            中斷處理流程圖: 



            IRQL(interrupt request level) - 中斷請求級別:


            每種中斷都有自己的優先級, 高優先級的中斷可以打斷低優先級的中斷的處理, 反之則不行。
            對應用層開發人員來說,最重要的是最下面的3個軟件中斷級別:
            (1) DPC/dispatch: 系統的線程調度器工作在這一級別, 它可以決定掛起和調度哪個線程。DPC(deferred procedure call)主要是給驅動程序用的,每個處理器都有一個DPC列表, 處理器在降級當前IRQL之前, 會先把DPC列表里的事情處理完。
            (2) APC: APC即asynchronous procedure call, 每個線程都有一個APC隊列, 我們可以往該隊列中加入自己要處理的事情(QueueUserAPC), 然后系統會在當該線程進入alertable wait state時調用我們加入的操作,我們可以通過SleepEx/WaitForMultipleObjectEx讓該線程進入這種等待狀態。我們常見的OVERLAPPED ReadFileEx/WriteFileEx就是通過這種方式實現的。
            (3) Passive/Low: 這個實際上不是一個IRQL, 我們普通的用戶代碼就運行在這個級別,所以它可以隨時被打斷。


            系統服務調用: 


            在Pentium II 之前, 0x2e中斷進入系統內核(eax傳遞服務號), Pentium II 之后處理器提供了Sysenter/Sysexit指令直接進出內核。
            內核對GUI線程和非GUI線程有不同的SSDT(System Services Descriptor Table), GUI線程服務分發表更完整,包含了窗口和GDI相關部分, 在第一調用user32/GDI相關的API時系統會修改該線程系統服務表的指針。


            內核對象結構: 


            應用層打交道的內核對象實際上是執行體對象, 它是有一個或多個真正的內核對象組成的。內核對象由對象頭和對象體組成, 對象頭對每種對象包含一致的結構, 對象體則每種對象各不相同。對象頭里的對象類型(object type), 對同種類型的對象,指向相同的地址,表明了該種對象的屬性和方法。對象管理器通過對象頭來管理內核對象。 


            內核對象同步原理:


            應用層我們經常調用WaitForSingle(Multiple)Object, 操作系統內部是怎么實現的?

            每個可同步的對象, 內部都有一個分發器頭(dispatch_header), 分發器頭包含了對象類型,狀態,以及等待該對象的線程列表;每個處于等待狀態的線程, 都有一個等待塊列表(wait block list), 每個等待塊代表一個等待線程。這樣就很好理解了,當我們把一個同步對象設置成有信號狀態時, 系統沿著分發器頭的等待線程列表遍歷,找到可激活的線程,將它轉入就緒狀態參與線程調度。


            Critical Section是如何實現用戶態等待的?

            我們知道CRITICAL_SECTION是同一進程內我們最常用的同步機制, 號稱不用轉入內核,以高效聞名, 它是怎么實現的?
            單純在用戶態等待, 我們只能死循環,不停的檢測, 也就是所謂的自旋鎖(SpinLock), critical section如果用這種方式實現,何來高效可言。
            實際上critical section的大概實現是這樣的: 它內部包含一個標志位以及一個event object, 進入critical section時首先嘗試設置標志位,如果設置成功,表示成功獲得資源;如果標志位已經被設置, 則等待event事件。其中標志位的設置是用類似interlockedexchange這樣的原子API操作的。這樣只要沒有資源競爭,大部分情況下都能滿足我們的高效需求, 如果有資源競爭,實際上還是會轉入內核態掛起線程。
            posted on 2016-03-22 22:48 Richard Wei 閱讀(2183) 評論(1)  編輯 收藏 引用 所屬分類: windows desktop

            FeedBack:
            # re: Windows系統機制筆記
            2016-04-13 11:00 | anna
            CRITICAL_SECTION是同一進程內我們最常用的同步機制  回復  更多評論
              
            久久精品亚洲乱码伦伦中文| 中文字幕成人精品久久不卡| 欧美无乱码久久久免费午夜一区二区三区中文字幕 | 麻豆成人久久精品二区三区免费| 亚洲欧美成人综合久久久 | 久久人人爽人人爽人人AV| 久久精品国产亚洲AV电影| 中文精品久久久久国产网址| 久久最新免费视频| av国内精品久久久久影院| 精品人妻伦一二三区久久| 亚洲AV日韩精品久久久久| 国产精品久久久久一区二区三区 | 久久综合九色综合精品| 午夜精品久久久久久影视777| 久久综合给合久久国产免费| 久久精品国产黑森林| 久久人妻少妇嫩草AV无码专区| 国内精品久久久久久不卡影院| 久久久久久久久66精品片| 日韩欧美亚洲综合久久影院d3| 2021国内精品久久久久久影院| 久久精品国产亚洲欧美| 精品综合久久久久久98| 99久久免费国产精品| 999久久久无码国产精品| yy6080久久| 四虎久久影院| 久久国产精品波多野结衣AV| 久久99国产精品久久99| 国内精品久久久久影院日本| 亚洲愉拍99热成人精品热久久| 亚洲国产成人精品91久久久| 狠狠色丁香婷婷综合久久来来去| 精品无码久久久久久尤物| 亚洲AV无一区二区三区久久| 久久99热这里只频精品6| 偷窥少妇久久久久久久久| 久久强奷乱码老熟女网站| 色青青草原桃花久久综合| 精品伊人久久久|