• <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>
            posts - 297,  comments - 15,  trackbacks - 0
            內核同步措施

                為了避免并發,防止競爭。內核提供了一組同步方法來提供對共享數據的保護。 我們的重點不是介紹這些方法的詳細用法,而是強調為什么使用這些方法和它們之間的差別。
                Linux 使用的同步機制可以說從2.0到2.6以來不斷發展完善。從最初的原子操作,到后來的信號量,從大內核鎖到今天的自旋鎖。這些同步機制的發展伴隨 Linux從單處理器到對稱多處理器的過度;伴隨著從非搶占內核到搶占內核的過度。鎖機制越來越有效,也越來越復雜。
                目前來說內核中原子操作多用來做計數使用,其它情況最常用的是兩種鎖以及它們的變種:一個是自旋鎖,另一個是信號量。我們下面就來著重介紹一下這兩種鎖機 制。


            自旋鎖
            ------------------------------------------------------
                自旋鎖是專為防止多處理器并發而引入的一種鎖,它在內核中大量應用于中斷處理等部分(對于單處理器來說,防止中斷處理中的并發可簡單采用關閉中斷的方式, 不需要自旋鎖)。
                自旋鎖最多只能被一個內核任務持有,如果一個內核任務試圖請求一個已被爭用(已經被持有)的自旋鎖,那么這個任務就會一直進行忙循環——旋轉——等待鎖重 新可用。
            要是鎖未被爭用,請求它的內核任務便能立刻得到它并且繼續進行。自旋鎖可以在任何時刻防止多于一個的內核任務同 時進入臨界區,因此這種鎖可有效地避免多處理器上并發運行的內核任務競爭共享資源。
                事實上,自旋鎖的初衷就是:在短期間內進行輕量級的鎖定。一個被爭用的自旋鎖使得請求它的線程在等待鎖重新可用的期間進行自旋(特別浪費處理器時間),所 以自旋鎖不應該被持有時間過長。如果需要長時間鎖定的話, 最好使用信號量。
            自旋鎖的基本形式如下:
                spin_lock(&mr_lock);
                //臨界區
                spin_unlock(&mr_lock);

                因為自旋鎖在同一時刻只能被最多一個內核任務持有,所以一個時刻只有一個線程允許存在于臨界區中。這點很好地滿足了對稱多處理機器需要的鎖定服務。在單處 理器上,自旋鎖僅僅當作一個設置內核搶占的開關。如果內核搶占也不存在,那么自旋鎖會在編譯時被完全剔除出內核。
                簡單的說,自旋鎖在內核中主要用來防止多處理器中并發訪問臨界區,防止 內核搶占造成的競爭。另外自旋鎖不允許任務睡眠(持有自旋鎖的任務睡眠會造成自死鎖——因為睡眠有可能造成持有鎖的內核 任務被重新調度,而再次申請自己已持有的鎖),它能夠在中斷上下文中使用
                死鎖:假設有一個或多個內核任務和一個或多個資源,每個內核都在等待其中的一個資源,但所有的資源都已經被占用了。這便會發生所有內核任務都在相互等待, 但它們永遠不會釋放已經占有的資源,于是任何內核任務都無法獲得所需要的資源,無法繼續運行,這便意味著死鎖發生了。自死瑣是說自己占有了某個資源,然后 自己又申請自己已占有的資源,顯然不可能再獲得該資源,因此就自縛手腳了。


            信號量
            ------------------------------------------------------
                Linux中的信號量是一種睡眠鎖。如果有一個任務試圖獲得一個已被持有的信號量時,信號量會將其推入等待隊列,然后讓其睡眠。這時處理器獲得自由去執行 其它代碼。當持有信號量的進程將信號量釋放后,在等待隊列中的一個任務將被喚醒,從而便可以獲得這個信號量。
                信號量的睡眠特性,使得信號量適用于鎖會被長時間持有的情況;只能在進程上下文中使用,因為中斷上下文中是不能被調度的;另外當代碼持有信號量時,不可以 再持有自旋鎖。

            信號量基本使用形式為:
            static DECLARE_MUTEX(mr_sem);//聲明互斥信號量
            if(down_interruptible(&mr_sem))
                //可被中斷的睡眠,當信號來到,睡眠的任務被喚醒
                //臨界區
            up(&mr_sem);


            信號量和自旋鎖區別
            ------------------------------------------------------
                雖然聽起來兩者之間的使用條件復雜,其實在實際使用中信號量和自旋鎖并不易混淆。注意以下原則:
                如果代碼需要睡眠——這往往是發生在和用戶空間同步時——使用信號量是唯一的選擇。由于不受睡眠的限制,使用信號量通常來說更加簡單一些。如果需要在自旋 鎖和信號量中作選擇,應該取決于鎖被持有的時間長短。理想情況是所有的鎖都應該盡可能短的被持有,但是如果鎖的持有時間較長的話,使用信號量是更好的選 擇。另外,信號量不同于自旋鎖,它不會關閉內核搶占,所以持有信號量的代碼可以被搶占。這意味者信號量不會對影響調度反應時間帶來負面影響。


            自旋鎖對信號量
            ------------------------------------------------------
            需求                     建議的加鎖方法

            低開銷加鎖               優先使用自旋鎖
            短期鎖定                 優先使用自旋鎖
            長期加鎖                 優先使用信號量
            中斷上下文中加鎖          使用自旋鎖
            持有鎖是需要睡眠、調度     使用信號量

            from:
            http://blog.chinaunix.net/u1/38576/showart_367985.html

            posted on 2010-04-01 11:50 chatler 閱讀(482) 評論(0)  編輯 收藏 引用 所屬分類: OS
            <2025年7月>
            293012345
            6789101112
            13141516171819
            20212223242526
            272829303112
            3456789

            常用鏈接

            留言簿(10)

            隨筆分類(307)

            隨筆檔案(297)

            algorithm

            Books_Free_Online

            C++

            database

            Linux

            Linux shell

            linux socket

            misce

            • cloudward
            • 感覺這個博客還是不錯,雖然做的東西和我不大相關,覺得看看還是有好處的

            network

            OSS

            • Google Android
            • Android is a software stack for mobile devices that includes an operating system, middleware and key applications. This early look at the Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.
            • os161 file list

            overall

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            久久天天躁狠狠躁夜夜网站| 国产成人久久久精品二区三区| 伊人久久大香线蕉精品不卡 | 久久精品无码一区二区WWW| 亚洲精品WWW久久久久久| 7777精品伊人久久久大香线蕉| 亚洲精品美女久久777777| 99久久婷婷国产综合亚洲| 久久久久亚洲AV无码专区桃色| 香港aa三级久久三级老师2021国产三级精品三级在| 久久久久亚洲AV无码专区网站| 亚洲精品乱码久久久久久蜜桃不卡| 国产高潮久久免费观看| 性高湖久久久久久久久| 久久久黄片| 青青草原综合久久| 久久国产精品一国产精品金尊| 亚洲精品高清一二区久久| 欧美777精品久久久久网| 久久人人爽人人爽人人片AV麻烦| 亚洲成色999久久网站| 久久久无码人妻精品无码| yy6080久久| 中文字幕精品久久久久人妻| 久久99久久无码毛片一区二区| 精品久久久久久久无码 | 无码久久精品国产亚洲Av影片 | 97久久天天综合色天天综合色hd| 久久影院午夜理论片无码| 99久久精品免费看国产| 久久久青草青青亚洲国产免观| 久久久久久无码Av成人影院| 亚洲国产精品久久电影欧美| 色综合久久夜色精品国产| 婷婷久久精品国产| 久久久久久久久波多野高潮| 久久久黄色大片| 久久久久se色偷偷亚洲精品av| 日产精品久久久久久久| 国产精品久久久久久久人人看| 狠狠色丁香婷婷久久综合|