發(fā)個簡單（易用）的內(nèi)存池

platinum

原帖由 Godbach 于 2010-1-12 10:07 發(fā)表


呵呵，白金兄這個問題還沒有解決啊。

是呀，一直很迷茫，小偉能不能幫我解釋一下

Godbach

原帖由 platinum 于 2010-1-12 10:14 發(fā)表

是呀，一直很迷茫，小偉能不能幫我解釋一下

很慚愧的說，我也不是很清楚。前段時間還特意為這個問題翻了一下LKD2等相關的書籍。只看到了底半和頂半的區(qū)別及應用的場合，感覺看的還是不很明白

duanjigang

原帖由 platinum 于 2010-1-12 09:49 發(fā)表
借這個貼子問一下
段兄為何使用 spin_lock 而不是 spin_lock_bh，什么情況下應該加 _bh 什么時候應該不加呢？

在LDD上翻出來看了看：
spin_lock_bh disables software interrupts
before taking the lock, but leaves hardware interrupts enabled.
spin_lock_bh通常用在進程中，用來禁止搶斷和禁止軟中斷，所以個人感覺這就跟試用場景有關了
如果你的代碼lock和unlock之間訪問的資源不會被一個中斷處理訪問的話，應該就不需要考慮禁止軟中斷了吧。
那樣就直接試用spin_lock,如果代碼片段很可能在中斷處理中執(zhí)行或者與中斷處理的程序訪問同一資源，
就應該調(diào)用spin_lock_irq或者spin_lock_bh吧
我的理解大概是這樣，再看看別的文章

[ 本帖最后由 duanjigang 于 2010-1-12 13:30 編輯 ]

duanjigang

原帖由 platinum 于 2010-1-12 10:14 發(fā)表

是呀，一直很迷茫，小偉能不能幫我解釋一下

對了，你的應用場景是什么？？這些API的區(qū)別是什么我沒仔細研究過，就用過read_lock,write_lock
還有就是這個spin_lock,也沒怎么求甚解，借這個機會，大家正好討論下

platinum

我的應用場景很簡單，寫基于 netfilter 的 hook 模塊，通過 netlink 與 userspace 交互
在內(nèi)核態(tài)工作時，有三個地方需要用到 lock 機制
1、收取 netlink 信令并插入鏈表
2、hook 中處理數(shù)據(jù)包時查找鏈表
3、timer 中 destroy 函數(shù)中有刪除鏈表的操作
為了安全起見，我都是用的是 _bh，不知道是不是沒必要，段兄這塊是怎么做的？

至于 rwlock、spinlock，我一般都是用 spinlock，只有在很多讀，很少寫的時候才使用 rwlock
但是我看文章說在極大讀，極小寫的時候可以改用 RCU 鎖，但 RCU 的應用場景很復雜，很多種情形，很多種用法，一頭霧水……

另一個問題，對于一個 spin_lock 變量，能否在不同地方使用不同的鎖
比如

fun1()
{
    spin_lock(&lock);
    do_something();
    spin_unlock(&lock);
}

fun2()
{
    spin_lock_bh(&lock);
    do_something();
    spin_unlock_bh(&lock);
}
同一個鎖，一個地方有 _bh，另一個沒有？是不是這也和應用場景有關，看是否需要對 local 進行 disable ？

[ 本帖最后由 platinum 于 2010-1-12 13:51 編輯 ]

Godbach

我們也有類似的應用。前兩種都用了_bh

duanjigang

原帖由 platinum 于 2010-1-12 13:44 發(fā)表
我的應用場景很簡單，寫基于 netfilter 的 hook 模塊，通過 netlink 與 userspace 交互
在內(nèi)核態(tài)工作時，有三個地方需要用到 lock 機制
1、收取 netlink 信令并插入鏈表
2、hook 中處理數(shù)據(jù)包時查找鏈表
3、 ...

netfilter的hook點是在softirq的上下文中,參考以下文章，我覺得你的用法至少是足夠了，而沒有欠缺,如果要采取更確切的
鎖操作api, 覺得netlink和timer中的鎖操作應該參考下文再分析下（還是結合場景）

     至于同一個spin_lock,個人覺得應該可以支持不同的操作，禁softirq或者不禁softirq都行，關鍵是你要保證lock和unlock的
操作類型是匹配的，也就是說bh_lock了，就要bh_unlock.當然，最好試驗下，感覺不頂事。

     白金兄有沒有在netlink通訊中遇到用戶態(tài)Sendmsg時阻塞的情況，有的話，大致是哪些原因？？？我做一個東西，偶爾會有
這種情況出現(xiàn)，一旦阻塞，再send就一直阻塞，除非重新加載模塊，不知道是不是鎖使用不當導致的。。。

  看了這文章，我一身冷汗，得趕緊查查我的代碼去。

獲得自旋鎖和釋放自旋鎖有好幾個版本，因此讓讀者知道在什么樣的情況下使用什么版本的獲得和釋放鎖的宏是非常必要的。

如果被保護的共享資源只在進程上下文訪問和軟中斷上下文訪問，那么當在進程上下文訪問共享資源時，可能被軟中斷打斷，從而可能進入軟中斷上下文來對被保護的共享資源訪問，因此對于這種情況，對共享資源的訪問必須使用spin_lock_bh和spin_unlock_bh來保護。當然使用spin_lock_irq和spin_unlock_irq以及spin_lock_irqsave和spin_unlock_irqrestore也可以，它們失效了本地硬中斷，失效硬中斷隱式地也失效了軟中斷。但是使用spin_lock_bh和spin_unlock_bh是最恰當?shù)模�它比其他兩個快。

如果被保護的共享資源只在進程上下文和tasklet或timer上下文訪問，那么應該使用與上面情況相同的獲得和釋放鎖的宏，因為tasklet和timer是用軟中斷實現(xiàn)的。

如果被保護的共享資源只在一個tasklet或timer上下文訪問，那么不需要任何自旋鎖保護，因為同一個tasklet或timer只能在一個CPU上運行，即使是在SMP環(huán)境下也是如此。實際上tasklet在調(diào)用tasklet_schedule標記其需要被調(diào)度時已經(jīng)把該tasklet綁定到當前CPU，因此同一個tasklet決不可能同時在其他CPU上運行。timer也是在其被使用add_timer添加到timer隊列中時已經(jīng)被幫定到當前CPU，所以同一個timer絕不可能運行在其他CPU上。當然同一個tasklet有兩個實例同時運行在同一個CPU就更不可能了。

如果被保護的共享資源只在兩個或多個tasklet或timer上下文訪問，那么對共享資源的訪問僅需要用spin_lock和spin_unlock來保護，不必使用_bh版本，因為當tasklet或timer運行時，不可能有其他tasklet或timer在當前CPU上運行。如果被保護的共享資源只在一個軟中斷（tasklet和timer除外）上下文訪問，那么這個共享資源需要用spin_lock和spin_unlock來保護，因為同樣的軟中斷可以同時在不同的CPU上運行。

如果被保護的共享資源在兩個或多個軟中斷上下文訪問，那么這個共享資源當然更需要用spin_lock和spin_unlock來保護，不同的軟中斷能夠同時在不同的CPU上運行。

如果被保護的共享資源在軟中斷（包括tasklet和timer）或進程上下文和硬中斷上下文訪問，那么在軟中斷或進程上下文訪問期間，可能被硬中斷打斷，從而進入硬中斷上下文對共享資源進行訪問，因此，在進程或軟中斷上下文需要使用spin_lock_irq和spin_unlock_irq來保護對共享資源的訪問。而在中斷處理句柄中使用什么版本，需依情況而定，如果只有一個中斷處理句柄訪問該共享資源，那么在中斷處理句柄中僅需要spin_lock和spin_unlock來保護對共享資源的訪問就可以了。因為在執(zhí)行中斷處理句柄期間，不可能被同一CPU上的軟中斷或進程打斷。但是如果有不同的中斷處理句柄訪問該共享資源，那么需要在中斷處理句柄中使用spin_lock_irq和spin_unlock_irq來保護對共享資源的訪問。

在使用spin_lock_irq和spin_unlock_irq的情況下，完全可以用spin_lock_irqsave和spin_unlock_irqrestore取代，那具體應該使用哪一個也需要依情況而定，如果可以確信在對共享資源訪問前中斷是使能的，那么使用spin_lock_irq更好一些，因為它比spin_lock_irqsave要快一些，但是如果你不能確定是否中斷使能，那么使用spin_lock_irqsave和spin_unlock_irqrestore更好，因為它將恢復訪問共享資源前的中斷標志而不是直接使能中斷。當然，有些情況下需要在訪問共享資源時必須中斷失效，而訪問完后必須中斷使能，這樣的情形使用spin_lock_irq和spin_unlock_irq最好。

需要特別提醒讀者，spin_lock用于阻止在不同CPU上的執(zhí)行單元對共享資源的同時訪問以及不同進程上下文互相搶占導致的對共享資源的非同步訪問，而中斷失效和軟中斷失效卻是為了阻止在同一CPU上軟中斷或中斷對共享資源的非同步訪問。

duanjigang

又找到兩篇好文章啊
Linux 內(nèi)核的同步機制，第 1 部分
http://www.ibm.com/developerworks/cn/linux/l-synch/part1/
Linux 內(nèi)核的同步機制，第 2 部分
http://www.ibm.com/developerworks/cn/linux/l-synch/part2/

ubuntuer

原帖由 duanjigang 于 2010-1-12 15:31 發(fā)表
又找到兩篇好文章啊
Linux 內(nèi)核的同步機制，第 1 部分
http://www.ibm.com/developerworks/cn/linux/l-synch/part1/
Linux 內(nèi)核的同步機制，第 2 部分
http://www.ibm.com/developerworks/cn/lin ...

看你們的討論受益匪淺
http://www.ibm.com/developerworks/cn/linux/上的文章向來經(jīng)典   去拜讀下

libra811

在init_mem_list函數(shù)里的第一次分配的話 ，是不是應該要添加一行代碼：
  if(!plist->list)
        {
            plist->list = p;
            plist->list->next = p;//添加代碼。否則在第二次循環(huán)時候的p->next指針為空，與第一次分配的不能形成鏈表
            plist->ptr = p;
            continue;
        }