Seq-locks vs RCU vs每CPU使用案例

Question

我想了解一些內核同步機制（順序鎖vs RCU（Read-Copy-Update）vs每CPU鎖）的不同用例用於編寫您的設備驅動程序或內核模塊。任何例子，將不勝感激。

Answer 1

順序鎖這是聰明的做法，以鎖定，其中作家獲得自旋鎖和讀者能夠避免完全鎖定，在不必重複不一致讀取的成本。這種方法最適合於經常讀取數據但很少更新的情況。 這裏多次讀取不會產生副作用，這與任何讀寫器鎖定和更新類似，不會同時混淆讀者。搜索它使用/包括API的/頭/數據結構的內核代碼：

#include <linux/seqlock.h> 
typedef struct { 
    unsigned seq; ===> seq is incremented every-time a writer acquires a lock 
    spinlock_t lock; 
} seqlock_t; 
write_seqlock(), write_sequnlock() 
read_seqlock(), read_sequnlock() 

注：序列編號遞增每一個作家獲取一個鎖，讀卡器，記錄序列號的副本時間，然後執行讀取，重新檢查序列號（使用read_seqretry（）），如果seq編號不一致，則讀取器必須重新讀取。對於有爭議的閱讀器來說，冗餘讀取並不比「旋轉」CPU要糟糕，因爲對於無爭議的閱讀器而言，可以一起避免所有自旋鎖。

RCU（讀取 - 拷貝更新）這分隔了更新和回收信息，讀者和作者都可以完全避免鎖定。 RCU主要用於處理動態分配的數據結構，如鏈接列表。RCU編寫器不會修改數據，而是分配一個新元素，並使用更新後的數據進行初始化。

PER-CPU變量這些大多數與CPU特定的結構一起使用可以避免全局鎖定。注意這些必須仍然與ISR同步。同樣的：

#include <linux/percpi.h> 
DEFINE_PER_CPU() 
per_cpu(var,cpu) 
get_cpu_var(), put_cpu_var() 

Answer 2

的seqlock documentation說：不用捱餓作家

讀/寫器一致的機制。這種類型的 鎖定數據，讀者需要一組一致的信息 ，並且如果信息發生變化，它願意重試。有兩種類型的讀取器 ：

1. 序列讀者從未阻止作家，但它們可以具有重試 如果作家正在進行通過檢測序列號的變化。作家不會等待序列閱讀器。
2. 鎖定閱讀器，如果作家或其他鎖定閱讀器 正在進行中，將鎖定閱讀器。正在進行的鎖定閱讀器也將阻止作家向前推進。與普通的rwlock不同，這裏的讀鎖是 ，因此只有一個鎖定讀卡器可以獲得它。

這不像brlock那樣緩存友好。另外，對於包含指針的數據，這可能效果不佳 因爲任何編寫者可能會使讀者所關注的指針無效。

預計無阻塞讀者用法：

do { 
    seq = read_seqbegin(&foo); 
    ... 
} while (read_seqretry(&foo, seq)); 

在非SMP的自旋鎖消失，但筆者仍然需要 遞增序列變量，因爲中斷例程可以 更改數據的狀態。

在Rusty的Unreliable Guide To Locking中解釋了RCU和每CPU鎖。