• <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 閱讀(476) 評論(0)  編輯 收藏 引用 所屬分類: OS
            <2010年8月>
            25262728293031
            1234567
            891011121314
            15161718192021
            22232425262728
            2930311234

            常用鏈接

            留言簿(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

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            精品久久久久久无码人妻热| 精品人妻伦一二三区久久| 青青草原综合久久大伊人导航| 国产视频久久| 成人综合伊人五月婷久久| 久久国产精品免费| 囯产精品久久久久久久久蜜桃| 久久国产精品一区二区| 日韩欧美亚洲综合久久| 久久精品国产99久久久香蕉| 久久免费国产精品一区二区| 久久综合给合久久国产免费| 国内精品久久久久影院亚洲| 久久久青草久久久青草| 国内精品伊人久久久久777| 色成年激情久久综合| 亚洲国产精品无码久久98| 亚洲αv久久久噜噜噜噜噜| 久久久久亚洲精品天堂久久久久久 | 国产成人久久精品区一区二区| 亚洲精品高清国产一线久久| 国产精品亚洲美女久久久| 2021精品国产综合久久| 精品久久久中文字幕人妻| 午夜天堂精品久久久久| 最新久久免费视频| 久久亚洲精品成人AV| 亚洲国产另类久久久精品黑人| 亚洲欧美国产精品专区久久| 丁香五月综合久久激情| 婷婷久久综合九色综合98| 伊人久久久AV老熟妇色| 久久综合色老色| 亚洲精品无码久久久久sm| 2020国产成人久久精品| 久久精品中文字幕一区| 香蕉久久av一区二区三区| 2022年国产精品久久久久| 久久99久久99小草精品免视看| 亚洲国产成人久久精品影视 | 2020国产成人久久精品|