• <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>
            操作系統(tǒng)運行中,種有各種事情打斷和切換,通過系統(tǒng)陷阱來實現(xiàn): 


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


            中斷處理流程圖: 



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


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


            系統(tǒng)服務調用: 


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


            內核對象結構: 


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


            內核對象同步原理:


            應用層我們經(jīng)常調用WaitForSingle(Multiple)Object, 操作系統(tǒng)內部是怎么實現(xiàn)的?

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


            Critical Section是如何實現(xiàn)用戶態(tài)等待的?

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

            FeedBack:
            # re: Windows系統(tǒng)機制筆記
            2016-04-13 11:00 | anna
            CRITICAL_SECTION是同一進程內我們最常用的同步機制  回復  更多評論
              
            久久青草国产手机看片福利盒子| 天堂无码久久综合东京热| 亚洲午夜无码久久久久| 久久婷婷五月综合色奶水99啪| 色欲久久久天天天综合网| 狠狠色丁香婷婷综合久久来| 久久国产精品免费一区| 亚洲精品蜜桃久久久久久| 99久久国产综合精品五月天喷水| 久久精品无码一区二区三区日韩 | 日韩AV无码久久一区二区| 99久久99久久精品国产片| 亚洲精品乱码久久久久久久久久久久 | 久久精品亚洲欧美日韩久久| 亚洲精品乱码久久久久久蜜桃图片 | 无码任你躁久久久久久老妇| 久久99热只有频精品8| 综合久久久久久中文字幕亚洲国产国产综合一区首 | 久久精品一区二区国产| 国产精品中文久久久久久久| 久久国产热这里只有精品| 91精品国产色综合久久| 亚洲精品乱码久久久久久中文字幕| 久久有码中文字幕| 久久成人18免费网站| 国产精品日韩深夜福利久久| 一本一道久久精品综合| 国产亚洲精久久久久久无码| 无码人妻精品一区二区三区久久久| 亚洲国产视频久久| 热99RE久久精品这里都是精品免费 | 国产亚洲精久久久久久无码AV| 久久r热这里有精品视频| 久久精品国内一区二区三区| 久久婷婷久久一区二区三区| 99热精品久久只有精品| 欧美伊人久久大香线蕉综合69| 久久精品国产一区二区三区不卡| 久久精品成人免费观看97| 香蕉久久夜色精品国产2020| 久久精品国产2020|