linux內存屏障

『壹』 如何實現linux下多線程之間的互斥與同步

Linux設備驅動中必須解決的一個問題是多個進程對共享資源的並發訪問，並發訪問會導致競態，linux提供了多種解決競態問題的方式，這些方式適合不同的應用場景。

Linux內核是多進程、多線程的操作系統，它提供了相當完整的內核同步方法。內核同步方法列表如下：
中斷屏蔽
原子操作
自旋鎖
讀寫自旋鎖
順序鎖
信號量
讀寫信號量
BKL（大內核鎖）
Seq鎖
一、並發與競態：
定義：
並發（concurrency）指的是多個執行單元同時、並行被執行，而並發的執行單元對共享資源（硬體資源和軟體上的全局變數、靜態變數等）的訪問則很容易導致競態（race conditions）。
在linux中，主要的競態發生在如下幾種情況：
1、對稱多處理器（SMP）多個CPU
特點是多個CPU使用共同的系統匯流排，因此可訪問共同的外設和存儲器。
2、單CPU內進程與搶占它的進程
3、中斷（硬中斷、軟中斷、Tasklet、底半部）與進程之間
只要並發的多個執行單元存在對共享資源的訪問，競態就有可能發生。
如果中斷處理程序訪問進程正在訪問的資源，則競態也會會發生。
多個中斷之間本身也可能引起並發而導致競態（中斷被更高優先順序的中斷打斷）。

解決競態問題的途徑是保證對共享資源的互斥訪問，所謂互斥訪問就是指一個執行單元在訪問共享資源的時候，其他的執行單元都被禁止訪問。

訪問共享資源的代碼區域被稱為臨界區，臨界區需要以某種互斥機制加以保護，中斷屏蔽，原子操作，自旋鎖，和信號量都是linux設備驅動中可採用的互斥途徑。

臨界區和競爭條件：
所謂臨界區（critical regions）就是訪問和操作共享數據的代碼段，為了避免在臨界區中並發訪問，編程者必須保證這些代碼原子地執行——也就是說，代碼在執行結束前不可被打斷，就如同整個臨界區是一個不可分割的指令一樣，如果兩個執行線程有可能處於同一個臨界區中，那麼就是程序包含一個bug，如果這種情況發生了，我們就稱之為競爭條件（race conditions），避免並發和防止競爭條件被稱為同步。

死鎖：
死鎖的產生需要一定條件：要有一個或多個執行線程和一個或多個資源，每個線程都在等待其中的一個資源，但所有的資源都已經被佔用了，所有線程都在相互等待，但它們永遠不會釋放已經佔有的資源，於是任何線程都無法繼續，這便意味著死鎖的發生。

二、中斷屏蔽
在單CPU范圍內避免競態的一種簡單方法是在進入臨界區之前屏蔽系統的中斷。
由於linux內核的進程調度等操作都依賴中斷來實現，內核搶占進程之間的並發也就得以避免了。
中斷屏蔽的使用方法：
local_irq_disable()//屏蔽中斷
//臨界區
local_irq_enable()//開中斷
特點：
由於linux系統的非同步IO，進程調度等很多重要操作都依賴於中斷，在屏蔽中斷期間所有的中斷都無法得到處理，因此長時間的屏蔽是很危險的，有可能造成數據丟失甚至系統崩潰，這就要求在屏蔽中斷之後，當前的內核執行路徑應當盡快地執行完臨界區的代碼。
中斷屏蔽只能禁止本CPU內的中斷，因此，並不能解決多CPU引發的競態，所以單獨使用中斷屏蔽並不是一個值得推薦的避免競態的方法，它一般和自旋鎖配合使用。

三、原子操作
定義：原子操作指的是在執行過程中不會被別的代碼路徑所中斷的操作。
（原子原本指的是不可分割的微粒，所以原子操作也就是不能夠被分割的指令）
（它保證指令以「原子」的方式執行而不能被打斷）
原子操作是不可分割的，在執行完畢不會被任何其它任務或事件中斷。在單處理器系統(UniProcessor)中，能夠在單條指令中完成的操作都可以認為是" 原子操作"，因為中斷只能發生於指令之間。這也是某些CPU指令系統中引入了test_and_set、test_and_clear等指令用於臨界資源互斥的原因。但是，在對稱多處理器(Symmetric Multi-Processor)結構中就不同了，由於系統中有多個處理器在獨立地運行，即使能在單條指令中完成的操作也有可能受到干擾。我們以decl (遞減指令)為例，這是一個典型的"讀－改－寫"過程，涉及兩次內存訪問。
通俗理解：
原子操作，顧名思義，就是說像原子一樣不可再細分。一個操作是原子操作，意思就是說這個操作是以原子的方式被執行，要一口氣執行完，執行過程不能夠被OS的其他行為打斷，是一個整體的過程，在其執行過程中，OS的其它行為是插不進來的。
分類：linux內核提供了一系列函數來實現內核中的原子操作，分為整型原子操作和位原子操作，共同點是：在任何情況下操作都是原子的，內核代碼可以安全的調用它們而不被打斷。

原子整數操作：
針對整數的原子操作只能對atomic_t類型的數據進行處理，在這里之所以引入了一個特殊的數據類型，而沒有直接使用C語言的int型，主要是出於兩個原因：
第一、讓原子函數只接受atomic_t類型的操作數，可以確保原子操作只與這種特殊類型數據一起使用，同時，這也確保了該類型的數據不會被傳遞給其它任何非原子函數；
第二、使用atomic_t類型確保編譯器不對相應的值進行訪問優化——這點使得原子操作最終接收到正確的內存地址，而不是一個別名，最後就是在不同體系結構上實現原子操作的時候，使用atomic_t可以屏蔽其間的差異。
原子整數操作最常見的用途就是實現計數器。
另一點需要說明原子操作只能保證操作是原子的，要麼完成，要麼不完成，不會有操作一半的可能，但原子操作並不能保證操作的順序性，即它不能保證兩個操作是按某個順序完成的。如果要保證原子操作的順序性，請使用內存屏障指令。
atomic_t和ATOMIC_INIT(i)定義
typedef struct { volatile int counter; } atomic_t;
#define ATOMIC_INIT(i) { (i) }

在你編寫代碼的時候，能使用原子操作的時候，就盡量不要使用復雜的加鎖機制，對多數體系結構來講，原子操作與更復雜的同步方法相比較，給系統帶來的開銷小，對高速緩存行的影響也小，但是，對於那些有高性能要求的代碼，對多種同步方法進行測試比較，不失為一種明智的作法。

原子位操作：
針對位這一級數據進行操作的函數，是對普通的內存地址進行操作的。它的參數是一個指針和一個位號。

為方便其間，內核還提供了一組與上述操作對應的非原子位函數，非原子位函數與原子位函數的操作完全相同，但是，前者不保證原子性，且其名字前綴多兩個下劃線。例如，與test_bit()對應的非原子形式是_test_bit()，如果你不需要原子性操作（比如，如果你已經用鎖保護了自己的數據），那麼這些非原子的位函數相比原子的位函數可能會執行得更快些。

四、自旋鎖
自旋鎖的引入：
如 果每個臨界區都能像增加變數這樣簡單就好了，可惜現實不是這樣，而是臨界區可以跨越多個函數，例如：先得從一個數據結果中移出數據，對其進行格式轉換和解 析，最後再把它加入到另一個數據結構中，整個執行過程必須是原子的，在數據被更新完畢之前，不能有其他代碼讀取這些數據，顯然，簡單的原子操作是無能為力 的（在單處理器系統(UniProcessor)中，能夠在單條指令中完成的操作都可以認為是" 原子操作"，因為中斷只能發生於指令之間），這就需要使用更為復雜的同步方法——鎖來提供保護。

自旋鎖的介紹：
Linux內核中最常見的鎖是自旋鎖（spin lock），自旋鎖最多隻能被一個可執行線程持有，如果一個執行線程試圖獲得一個被爭用（已經被持有）的自旋鎖，那麼該線程就會一直進行忙循環—旋轉—等待鎖重新可用，要是鎖未被爭用，請求鎖的執行線程便能立刻得到它，繼續執行，在任意時間，自旋鎖都可以防止多於一個的執行線程同時進入理解區，注意同一個鎖可以用在多個位置—例如，對於給定數據的所有訪問都可以得到保護和同步。
一個被爭用的自旋鎖使得請求它的線程在等待鎖重新可用時自旋（特別浪費處理器時間），所以自旋鎖不應該被長時間持有，事實上，這點正是使用自旋鎖的初衷，在短期間內進行輕量級加鎖，還可以採取另外的方式來處理對鎖的爭用：讓請求線程睡眠，直到鎖重新可用時再喚醒它，這樣處理器就不必循環等待，可以去執行其他代碼，這也會帶來一定的開銷——這里有兩次明顯的上下文切換， 被阻塞的線程要換出和換入。因此，持有自旋鎖的時間最好小於完成兩次上下文切換的耗時，當然我們大多數人不會無聊到去測量上下文切換的耗時，所以我們讓持 有自旋鎖的時間應盡可能的短就可以了，信號量可以提供上述第二種機制，它使得在發生爭用時，等待的線程能投入睡眠，而不是旋轉。
自旋鎖可以使用在中斷處理程序中（此處不能使用信號量，因為它們會導致睡眠），在中斷處理程序中使用自旋鎖時，一定要在獲取鎖之前，首先禁止本地中斷（在 當前處理器上的中斷請求），否則，中斷處理程序就會打斷正持有鎖的內核代碼，有可能會試圖去爭用這個已經持有的自旋鎖，這樣以來，中斷處理程序就會自旋， 等待該鎖重新可用，但是鎖的持有者在這個中斷處理程序執行完畢前不可能運行，這正是我們在前一章節中提到的雙重請求死鎖，注意，需要關閉的只是當前處理器上的中斷，如果中斷發生在不同的處理器上，即使中斷處理程序在同一鎖上自旋，也不會妨礙鎖的持有者（在不同處理器上）最終釋放鎖。

自旋鎖的簡單理解：
理解自旋鎖最簡單的方法是把它作為一個變數看待，該變數把一個臨界區或者標記為「我當前正在運行，請稍等一會」或者標記為「我當前不在運行，可以被使用」。如果A執行單元首先進入常式，它將持有自旋鎖，當B執行單元試圖進入同一個常式時，將獲知自旋鎖已被持有，需等到A執行單元釋放後才能進入。

自旋鎖的API函數：

其實介紹的幾種信號量和互斥機制，其底層源碼都是使用自旋鎖,可以理解為自旋鎖的再包裝。所以從這里就可以理解為什麼自旋鎖通常可以提供比信號量更高的性能。
自旋鎖是一個互斥設備，他只能會兩個值：「鎖定」和「解鎖」。它通常實現為某個整數之中的單個位。
「測試並設置」的操作必須以原子方式完成。
任何時候，只要內核代碼擁有自旋鎖，在相關CPU上的搶占就會被禁止。
適用於自旋鎖的核心規則：
（1）任何擁有自旋鎖的代碼都必須使原子的，除服務中斷外（某些情況下也不能放棄CPU,如中斷服務也要獲得自旋鎖。為了避免這種鎖陷阱，需要在擁有自旋鎖時禁止中斷），不能放棄CPU（如休眠，休眠可發生在許多無法預期的地方）。否則CPU將有可能永遠自旋下去（死機）。
（2）擁有自旋鎖的時間越短越好。

需 要強調的是，自旋鎖別設計用於多處理器的同步機制，對於單處理器（對於單處理器並且不可搶占的內核來說，自旋鎖什麼也不作），內核在編譯時不會引入自旋鎖 機制，對於可搶占的內核，它僅僅被用於設置內核的搶占機制是否開啟的一個開關，也就是說加鎖和解鎖實際變成了禁止或開啟內核搶占功能。如果內核不支持搶 占，那麼自旋鎖根本就不會編譯到內核中。
內核中使用spinlock_t類型來表示自旋鎖，它定義在：
typedef struct {
raw_spinlock_t raw_lock;
#if defined(CONFIG_PREEMPT) && defined(CONFIG_SMP)
unsigned int break_lock;
#endif
} spinlock_t;

對於不支持SMP的內核來說，struct raw_spinlock_t什麼也沒有，是一個空結構。對於支持多處理器的內核來說，struct raw_spinlock_t定義為
typedef struct {
unsigned int slock;
} raw_spinlock_t;

slock表示了自旋鎖的狀態，「1」表示自旋鎖處於解鎖狀態（UNLOCK），「0」表示自旋鎖處於上鎖狀態（LOCKED）。
break_lock表示當前是否由進程在等待自旋鎖，顯然，它只有在支持搶占的SMP內核上才起作用。
自旋鎖的實現是一個復雜的過程，說它復雜不是因為需要多少代碼或邏輯來實現它，其實它的實現代碼很少。自旋鎖的實現跟體系結構關系密切，核心代碼基本也是由匯編語言寫成，與體協結構相關的核心代碼都放在相關的目錄下，比如。對於我們驅動程序開發人員來說，我們沒有必要了解這么spinlock的內部細節，如果你對它感興趣，請參考閱讀Linux內核源代碼。對於我們驅動的spinlock介面，我們只需包括頭文件。在我們詳細的介紹spinlock的API之前，我們先來看看自旋鎖的一個基本使用格式：
#include
spinlock_t lock = SPIN_LOCK_UNLOCKED;

spin_lock(&lock);
....
spin_unlock(&lock);

從使用上來說，spinlock的API還很簡單的，一般我們會用的的API如下表，其實它們都是定義在中的宏介面，真正的實現在中
#include
SPIN_LOCK_UNLOCKED
DEFINE_SPINLOCK
spin_lock_init( spinlock_t *)
spin_lock(spinlock_t *)
spin_unlock(spinlock_t *)
spin_lock_irq(spinlock_t *)
spin_unlock_irq(spinlock_t *)
spin_lock_irqsace(spinlock_t *，unsigned long flags)
spin_unlock_irqsace(spinlock_t *, unsigned long flags)
spin_trylock(spinlock_t *)
spin_is_locked(spinlock_t *)

• 初始化
spinlock有兩種初始化形式，一種是靜態初始化，一種是動態初始化。對於靜態的spinlock對象，我們用 SPIN_LOCK_UNLOCKED來初始化，它是一個宏。當然，我們也可以把聲明spinlock和初始化它放在一起做，這就是 DEFINE_SPINLOCK宏的工作，因此，下面的兩行代碼是等價的。
DEFINE_SPINLOCK (lock);
spinlock_t lock = SPIN_LOCK_UNLOCKED;

spin_lock_init 函數一般用來初始化動態創建的spinlock_t對象，它的參數是一個指向spinlock_t對象的指針。當然，它也可以初始化一個靜態的沒有初始化的spinlock_t對象。
spinlock_t *lock
......
spin_lock_init(lock);

• 獲取鎖
內核提供了三個函數用於獲取一個自旋鎖。
spin_lock：獲取指定的自旋鎖。
spin_lock_irq：禁止本地中斷並獲取自旋鎖。
spin_lock_irqsace：保存本地中斷狀態，禁止本地中斷並獲取自旋鎖，返回本地中斷狀態。

自旋鎖是可以使用在中斷處理程序中的，這時需要使用具有關閉本地中斷功能的函數，我們推薦使用 spin_lock_irqsave，因為它會保存加鎖前的中斷標志，這樣就會正確恢復解鎖時的中斷標志。如果spin_lock_irq在加鎖時中斷是關閉的，那麼在解鎖時就會錯誤的開啟中斷。

另外兩個同自旋鎖獲取相關的函數是：
spin_trylock()：嘗試獲取自旋鎖，如果獲取失敗則立即返回非0值，否則返回0。
spin_is_locked()：判斷指定的自旋鎖是否已經被獲取了。如果是則返回非0，否則，返回0。
• 釋放鎖
同獲取鎖相對應，內核提供了三個相對的函數來釋放自旋鎖。
spin_unlock：釋放指定的自旋鎖。
spin_unlock_irq：釋放自旋鎖並激活本地中斷。
spin_unlock_irqsave：釋放自旋鎖，並恢復保存的本地中斷狀態。

五、讀寫自旋鎖
如 果臨界區保護的數據是可讀可寫的，那麼只要沒有寫操作，對於讀是可以支持並發操作的。對於這種只要求寫操作是互斥的需求，如果還是使用自旋鎖顯然是無法滿 足這個要求（對於讀操作實在是太浪費了）。為此內核提供了另一種鎖－讀寫自旋鎖，讀自旋鎖也叫共享自旋鎖，寫自旋鎖也叫排他自旋鎖。
讀寫自旋鎖是一種比自旋鎖粒度更小的鎖機制，它保留了「自旋」的概念，但是在寫操作方面，只能最多有一個寫進程，在讀操作方面，同時可以有多個讀執行單元，當然，讀和寫也不能同時進行。
讀寫自旋鎖的使用也普通自旋鎖的使用很類似，首先要初始化讀寫自旋鎖對象：
// 靜態初始化
rwlock_t rwlock = RW_LOCK_UNLOCKED;
//動態初始化
rwlock_t *rwlock;
...
rw_lock_init(rwlock);

在讀操作代碼里對共享數據獲取讀自旋鎖：
read_lock(&rwlock);
...
read_unlock(&rwlock);

在寫操作代碼里為共享數據獲取寫自旋鎖：
write_lock(&rwlock);
...
write_unlock(&rwlock);

需要注意的是，如果有大量的寫操作，會使寫操作自旋在寫自旋鎖上而處於寫飢餓狀態（等待讀自旋鎖的全部釋放），因為讀自旋鎖會自由的獲取讀自旋鎖。

讀寫自旋鎖的函數類似於普通自旋鎖，這里就不一一介紹了，我們把它列在下面的表中。
RW_LOCK_UNLOCKED
rw_lock_init(rwlock_t *)
read_lock(rwlock_t *)
read_unlock(rwlock_t *)
read_lock_irq(rwlock_t *)
read_unlock_irq(rwlock_t *)
read_lock_irqsave(rwlock_t *, unsigned long)
read_unlock_irqsave(rwlock_t *, unsigned long)
write_lock(rwlock_t *)
write_unlock(rwlock_t *)
write_lock_irq(rwlock_t *)
write_unlock_irq(rwlock_t *)
write_lock_irqsave(rwlock_t *, unsigned long)
write_unlock_irqsave(rwlock_t *, unsigned long)
rw_is_locked(rwlock_t *)
六、順序瑣
順序瑣（seqlock）是對讀寫鎖的一種優化，若使用順序瑣，讀執行單元絕不會被寫執行單元阻塞，也就是說，讀執行單元可以在寫執行單元對被順序瑣保護的共享資源進行寫操作時仍然可以繼續讀，而不必等待寫執行單元完成寫操作，寫執行單元也不需要等待所有讀執行單元完成讀操作才去進行寫操作。
但是，寫執行單元與寫執行單元之間仍然是互斥的，即如果有寫執行單元在進行寫操作，其它寫執行單元必須自旋在哪裡，直到寫執行單元釋放了順序瑣。
如果讀執行單元在讀操作期間，寫執行單元已經發生了寫操作，那麼，讀執行單元必須重新讀取數據，以便確保得到的數據是完整的，這種鎖在讀寫同時進行的概率比較小時，性能是非常好的，而且它允許讀寫同時進行，因而更大的提高了並發性，
注意，順序瑣由一個限制，就是它必須被保護的共享資源不含有指針，因為寫執行單元可能使得指針失效，但讀執行單元如果正要訪問該指針，將導致Oops。
七、信號量
Linux中的信號量是一種睡眠鎖，如果有一個任務試圖獲得一個已經被佔用的信號量時，信號量會將其推進一個等待隊列，然後讓其睡眠，這時處理器能重獲自由，從而去執行其它代碼，當持有信號量的進程將信號量釋放後，處於等待隊列中的哪個任務被喚醒，並獲得該信號量。
信號量，或旗標，就是我們在操作系統里學習的經典的P/V原語操作。
P：如果信號量值大於0，則遞減信號量的值，程序繼續執行，否則，睡眠等待信號量大於0。
V：遞增信號量的值，如果遞增的信號量的值大於0，則喚醒等待的進程。

信號量的值確定了同時可以有多少個進程可以同時進入臨界區，如果信號量的初始值始1，這信號量就是互斥信號量（MUTEX）。對於大於1的非0值信號量，也可稱為計數信號量（counting semaphore）。對於一般的驅動程序使用的信號量都是互斥信號量。
類似於自旋鎖，信號量的實現也與體系結構密切相關，具體的實現定義在頭文件中，對於x86_32系統來說，它的定義如下：
struct semaphore {
atomic_t count;
int sleepers;
wait_queue_head_t wait;
};

信號量的初始值count是atomic_t類型的，這是一個原子操作類型，它也是一個內核同步技術，可見信號量是基於原子操作的。我們會在後面原子操作部分對原子操作做詳細介紹。

信號量的使用類似於自旋鎖，包括創建、獲取和釋放。我們還是來先展示信號量的基本使用形式：
static DECLARE_MUTEX(my_sem);
......
if (down_interruptible(&my_sem))

{
return -ERESTARTSYS;
}
......
up(&my_sem)

Linux內核中的信號量函數介面如下：
static DECLARE_SEMAPHORE_GENERIC(name, count);
static DECLARE_MUTEX(name);
seam_init(struct semaphore *, int);
init_MUTEX(struct semaphore *);
init_MUTEX_LOCKED(struct semaphore *)
down_interruptible(struct semaphore *);
down(struct semaphore *)
down_trylock(struct semaphore *)
up(struct semaphore *)
• 初始化信號量
信號量的初始化包括靜態初始化和動態初始化。靜態初始化用於靜態的聲明並初始化信號量。
static DECLARE_SEMAPHORE_GENERIC(name, count);
static DECLARE_MUTEX(name);

對於動態聲明或創建的信號量，可以使用如下函數進行初始化：
seam_init(sem, count);
init_MUTEX(sem);
init_MUTEX_LOCKED(struct semaphore *)

顯然，帶有MUTEX的函數始初始化互斥信號量。LOCKED則初始化信號量為鎖狀態。
• 使用信號量
信號量初始化完成後我們就可以使用它了
down_interruptible(struct semaphore *);
down(struct semaphore *)
down_trylock(struct semaphore *)
up(struct semaphore *)

down函數會嘗試獲取指定的信號量，如果信號量已經被使用了，則進程進入不可中斷的睡眠狀態。down_interruptible則會使進程進入可中斷的睡眠狀態。關於進程狀態的詳細細節，我們在內核的進程管理里在做詳細介紹。

down_trylock嘗試獲取信號量， 如果獲取成功則返回0，失敗則會立即返回非0。

當退出臨界區時使用up函數釋放信號量，如果信號量上的睡眠隊列不為空，則喚醒其中一個等待進程。

八、讀寫信號量
類似於自旋鎖，信號量也有讀寫信號量。讀寫信號量API定義在頭文件中，它的定義其實也是體系結構相關的，因此具體實現定義在頭文件中，以下是x86的例子：
struct rw_semaphore {
signed long count;
spinlock_t wait_lock;
struct list_head wait_list;
};

『貳』 LINUX設備驅動程序如何與硬體通信

LINUX設備驅動程序是怎麼樣和硬體通信的?下面將由我帶大家來解答這個疑問吧，希望對大家有所收獲!

LINUX設備驅動程序與硬體設備之間的通信

設備驅動程序是軟體概念和硬體電路之間的一個抽象層，因此兩方面都要討論。到目前為止，我們已經討論詳細討論了軟體概念上的一些細節，現在討論另一方面，介紹驅動程序在Linux上如何在保持可移植性的前提下訪問I/O埠和I/O內存。

我們在需要示例的場合會使用簡單的數字I/O埠來講解I/O指令，並使用普通的幀緩沖區顯存來講解內存映射I/O。

I/O埠和I/O內存

計算機對每種外設都是通過讀寫它的寄存器進行控制的。大部分外設都有幾個寄存器，不管是在內存地址空間還是在I/O地址空間，這些寄存器的訪問地址都是連續的。

I/O埠就是I/O埠，設備會把寄存器映射到I/O埠，不管處理器是否具有獨立的I/O埠地址空間。即使沒有在訪問外設時也要模擬成讀寫I/O埠。

I/O內存是設備把寄存器映射到某個內存地址區段(如PCI設備)。這種I/O內存通常是首先方案，它不需要特殊的處理器指令，而且CPU核心訪問內存更有效率。

I/O寄存器和常規內存

盡管硬體寄存器和內存非常相似，但程序員在訪問I/O寄存器的時候必須注意避免由於CPU或編譯器不恰當的優化而改變預期的I/O動作。

I/O寄存器和RAM最主要的區別就是I/O操作具有邊際效應，而內存操作則沒有：由於內存沒有邊際效應，所以可以用多種 方法 進行優化，如使用高速緩存保存數值、重新排序讀/寫指令等。

編譯器能夠將數值緩存在CPU寄存器中而不寫入內存，即使儲存數據，讀寫操作也都能在高速緩存中進行而不用訪問物理RAM。無論是在編譯器一級或是硬體一級，指令的重新排序都有可能發生：一個指令序列如果以不同於程序文本中的次序運行常常能執行得更快。

在對常規內存進行這些優化的時候，優化過程是透明的，而且效果良好，但是對I/O操作來說這些優化很可能造成致命的錯誤，這是因為受到邊際效應的干擾，而這卻是驅動程序訪問I/O寄存器的主要目的。處理器無法預料某些 其它 進程(在另一個處理器上運行，或在在某個I/O控制器中發生的操作)是否會依賴於內存訪問的順序。編譯器或CPU可能會自作聰明地重新排序所要求的操作，結果會發生奇怪的錯誤，並且很難調度。因此，驅動程序必須確保不使用高速緩沖，並且在訪問寄存器時不發生讀或寫指令的重新排序。

由硬體自身引起的問題很解決：只要把底層硬體配置成(可以是自動的或是由Linux初始化代碼完成)在訪問I/O區域(不管是內存還是埠)時禁止硬體緩存即可。

由編譯器優化和硬體重新排序引起的問題的解決辦法是：對硬體(或其他處理器)必須以特定順序的操作之間設置內存屏障(memory barrier)。Linux提供了4個宏來解決所有可能的排序問題：

#include <linux/kernel.h>

void barrier(void)

這個函數通知編譯器插入一個內存屏障，但對硬體沒有影響。編譯後的代碼會把當前CPU寄存器中的所有修改過的數值保存到內存中，需要這些數據的時候再重新讀出來。對barrier的調用可避免在屏障前後的編譯器優化，但硬體完成自己的重新排序。

#include <asm/system.h>

void rmb(void);

void read_barrier_depends(void);

void wmb(void);

void mb(void);

這些函數在已編譯的指令流中插入硬體內存屏障;具體實現方法是平台相關的。rmb(讀內存屏障)保證了屏障之前的讀操作一定會在後來的讀操作之前完成。wmb保證寫操作不會亂序，mb指令保證了兩者都不會。這些函數都是barrier的超集。

void smp_rmb(void);

void smp_read_barrier_depends(void);

void smp_wmb(void);

void smp_mb(void);

上述屏障宏版本也插入硬體屏障，但僅僅在內核針對SMP系統編譯時有效;在單處理器系統上，它們均會被擴展為上面那些簡單的屏障調用。

設備驅動程序中使用內存屏障的典型形式如下：

writel(dev->registers.addr, io_destination_address);

writel(dev->registers.size, io_size);

writel(dev->registers.operation, DEV_READ);

wmb();

writel(dev->registers.control, DEV_GO);

在這個例子中，最重要的是要確保控制某種特定操作的所有設備寄存器一定要在操作開始之前已被正確設置。其中的內存屏障會強制寫操作以要求的順序完成。

因為內存屏障會影響系統性能，所以應該只用於真正需要的地方。不同類型的內存屏障對性能的影響也不盡相同，所以最好盡可能使用最符合需要的特定類型。

值得注意的是，大多數處理同步的內核原語，如自旋鎖和atomic_t操作，也能作為內存屏障使用。同時還需要注意，某些外設匯流排(比如PCI匯流排)存在自身的高速緩存問題，我們將在後面的章節中討論相關問題。

在某些體系架構上，允許把賦值語句和內存屏障進行合並以提高效率。內核提供了幾個執行這種合並的宏，在默認情況下，這些宏的定義如下：

#define set_mb(var, value) do {var = value; mb();} while 0

#define set_wmb(var, value) do {var = value; wmb();} while 0

#define set_rmb(var, value) do {var = value; rmb();} while 0

在適當的地方，<asm/system.h>中定義的這些宏可以利用體系架構特有的指令更快的完成任務。注意只有小部分體系架構定義了set_rmb宏。

使用I/O埠

I/O埠是驅動程序與許多設備之間的通信方式——至少在部分時間是這樣。本節講解了使用I/O埠的不同函數，另外也涉及到一些可移植性問題。

I/O埠分配

下面我們提供了一個注冊的介面，它允允許驅動程序聲明自己需要操作的埠：

#include <linux/ioport.h>

struct resource *request_region(unsigned long first, unsigned long n, const char *name);

它告訴內核，我們要使用起始於first的n個埠。name是設備的名稱。如果分配成功返回非NULL，如果失敗返回NULL。

所有分配的埠可從/proc/ioports中找到。如果我們無法分配到我們要的埠集合，則可以查看這個文件哪個驅動程序已經分配了這些埠。

如果不再使用這些埠，則用下面函數返回這些埠給系統：

void release_region(unsigned long start, unsigned long n);

下面函數允許驅動程序檢查給定的I/O埠是否可用：

int check_region(unsigned long first, unsigned long n);//不可用返回負的錯誤代碼

我們不贊成用這個函數，因為它返回成功並不能確保分配能夠成功，因為檢查和其後的分配並不是原子操作。我們應該始終使用request_region，因為這個函數執行了必要的鎖定，以確保分配過程以安全原子的方式完成。

操作I/O埠

當驅動程序請求了需要使用的I/O埠范圍後，必須讀取和/或寫入這些埠。為此，大多數硬體都會把8位、16位、32位區分開來。它們不能像訪問系統內存那樣混淆使用。

因此，C語言程序必須調用不同的函數訪問大小不同的埠。那些只支持映射的I/O寄存器的計算機體系架構通過把I/O埠地址重新映射到內存地址來偽裝埠I/O，並且為了易於移植，內核對驅動程序隱藏了這些細節。Linux內核頭文件中(在與體系架構相關的頭文件<asm/io.h>中)定義了如下一些訪問I/O埠的內聯函數：

unsigned inb(unsigned port);

void outb(unsigned char byte, unsigned port);

位元組讀寫埠。

unsigned inw(unsigned port);

void outw(unsigned short word, unsigned port);

訪問16位埠

unsigned inl(unsigned port);

void outl(unsigned longword, unsigned port);

訪問32位埠

在用戶空間訪問I/O埠

上面這些函數主要是提供給設備驅動程序使用的，但它們也可以用戶空間使用，至少在PC類計算機上可以使用。GNU的C庫在<sys/io.h>中定義了這些函數。如果要要用戶空間使用inb及相關函數，則必須滿足正下面這些條件：

編譯程序時必須帶有-O選項來強制內聯函數的展開。

必須用ioperm(獲取單個埠的許可權)或iopl(獲取整個I/O空間)系統調用來獲取對埠進行I/O操作的許可權。這兩個函數都是x86平台特有的。

必須以root身份運行該程序才能調用ioperm或iopl。或者進程的祖先進程之一已經以root身份獲取對埠的訪問。

如果宿主平台沒有以上兩個系統調用，則用戶空間程序仍然可以使用/dev/port設備文件訪問I/O埠。不過要注意，該設備文件的含義與平台密切相關，並且除PC平台以處，它幾乎沒有什麼用處。

串操作

以上的I/O操作都是一次傳輸一個數據，作為補充，有些處理器實現了一次傳輸一個數據序列的特殊指令，序列中的數據單位可以是位元組、字、雙字。這些指令稱為串操作指令，它們執行這些任務時比一個C語言編寫的循環語句快得多。下面列出的宏實現了串I/O：

void insb(unsigned port, void *addr, unsigned long count);

void outsb(unsigned port, void *addr, unsigned long count);從內存addr開始連續讀/寫count數目的位元組。只對單一埠port讀取或寫入數據

void insw(unsigned port, void *addr, unsigned long count);

void outsw(unsigned port, void *addr, unsigned long count);對一個16位埠讀寫16位數據

void insl(unsigned port, void *addr, unsigned long count);

void outsl(unsigned port, void *addr, unsigned long count);對一個32位埠讀寫32位數據

在使用串I/O操作函數時，需要銘記的是：它們直接將位元組流從埠中讀取或寫入。因此，當埠和主機系統具有不同的位元組序時，將導致不可預期的結果。使用inw讀取埠將在必要時交換位元組，以便確保讀入的值匹配於主機的位元組序。然而，串函數不會完成這種交換。

暫停式I/O

在處理器試圖從匯流排上快速傳輸數據時，某些平台(特別是i386)就會出現問題。當處理器時鍾比外設時鍾(如ISA)快時就會出現問題，並且在設備板上特別慢時表現出來。為了防止出現丟失數據的情況，可以使用暫停式的I/O函數來取代通常的I/O函數，這些暫停式的I/O函數很像前面介紹的那些I/O函數，不同之處是它們的名字用_p結尾，如inb_p、outb_p等等。在linux支持的大多數平台上都定義了這些函數，不過它們常常擴展為非暫停式I/O同樣的代碼，因為如果不使用過時的外設匯流排就不需要額外的暫停。

平台相關性

I/O指令是與處理器密切相關的。因為它們的工作涉及到處理器移入移出數據的細節，所以隱藏平台間的差異非常困難。因此，大部分與I/O埠相關的源代碼都與平台相關。

回顧前面函數列表可以看到有一處不兼容的地方，即數據類型。函數的參數根據各平台體系架構上的不同要相應地使用不同的數據類型。例如，port參數在x86平台上(處理器只支持64KB的I/O空間)上定義為unsigned short，但在其他平台上定義為unsigned long，在這些平台上，埠是與內存在同一地址空間內的一些特定區域。

感興趣的讀者可以從io.h文件獲得更多信息，除了本章介紹的函數，一些與體系架構相關的函數有時也由該文件定義。

值得注意的是，x86家族之外的處理器都不為埠提供獨立的地址空間。

I/O操作在各個平台上執行的細節在對應平台的編程手冊中有詳細的敘述;也可以從web上下載這些手冊的PDF文件。

I/O埠示例

演示設備驅動程序的埠I/O的示例代碼運行於通用的數字I/O埠上，這種埠在大多數計算機平台上都能找到。

數字I/O埠最常見的一種形式是一個位元組寬度的I/O區域，它或者映射到內存，或者映射到埠。當把數字寫入到輸出區域時，輸出引腳上的電平信號隨著寫入的各位而發生相應變化。從輸入區域讀取到的數據則是輸入引腳各位當前的邏輯電平值。

這類I/O埠的具體實現和軟體介面是因系統而異的。大多數情況下，I/O引腳由兩個I/O區域控制的：一個區域中可以選擇用於輸入和輸出的引腳，另一個區域中可以讀寫實際的邏輯電平。不過有時情況簡單些，每個位不是輸入就是輸出(不過這種情況下就不能稱為“通用I/O"了);在所有個人計算機上都能找到的並口就是這樣的非通用的I/O埠。

並口簡介

並口的最小配置由3個8位埠組成。第一個埠是一個雙向的數據寄存器，它直接連接到物理連接器的2~9號引腳上。第二個埠是一個只讀的狀態寄存器;當並口連接列印機時，該寄存器 報告 列印機狀態，如是否是線、缺紙、正忙等等。第三個埠是一個只用於輸出的控制寄存器，它的作用之一是控制是否啟用中斷。

如下所示：並口的引腳

示例驅動程序

while(count--) {

outb(*(ptr++), port);

wmb();

}

使用I/O內存

除了x86上普遍使的I/O埠之外，和設備通信的另一種主要機制是通過使用映射到內存的寄存器或設備內存，這兩種都稱為I/O內存，因為寄存器和內存的差別對軟體是透明的。

I/O內存僅僅是類似RAM的一個區域，在那裡處理器可以通過匯流排訪問設備。這種內存有很多用途，比如存放視頻數據或乙太網數據包，也可以用來實現類似I/O埠的設備寄存器(也就是說，對它們的讀寫也存在邊際效應)。

根據計算機平台和所使用匯流排的不同，i/o內存可能是，也可能不是通過頁表訪問的。如果訪問是經由頁表進行的，內核必須首先安排物理地址使其對設備驅動程序可見(這通常意味著在進行任何I/O之前必須先調用ioremap)。如果訪問無需頁表，那麼I/O內存區域就非常類似於I/O埠，可以使用適當形式的函數讀取它們。

不管訪問I/O內存是否需要調用ioremap，都不鼓勵直接使用指向I/O內存的指針。相反使用包裝函數訪問I/O內存，這一方面在所有平台上都是安全的，另一方面，在可以直接對指針指向的內存區域執行操作的時候，這些函數是經過優化的。並且直接使用指針會影響程序的可移植性。

I/O內存分配和映射

在使用之前，必須首先分配I/O區域。分配內存區域的介面如下(在<linux/ioport.h>中定義)：

struct resource *request_mem_region(unsigned long start, unsigned long len, char *name);

該函數從start開始分配len位元組長的內存區域。如果成功返回非NULL，否則返回NULL值。所有的I/O內存分配情況可從/proc/iomem得到。

不再使用已分配的內存區域時，使用如下介面釋放：

void release_mem_region(unsigned long start, unsigned long len);

下面函數用來檢查給定的I/O內存區域是否可用的老函數：

int check_mem_region(unsigned long start, unsigned long len);//這個函數和check_region一樣不安全，應避免使用

分配內存之後我們還必須確保該I/O內存對內存而言是可訪問的。獲取I/O內存並不意味著可引用對應的指針;在許多系統上，I/O內存根本不能通過這種方式直接訪問。因此，我們必須由ioremap函數建立映射，ioremap專用於為I/O內存區域分配虛擬地址。

我們根據以下定義來調用ioremap函數：

#include <asm/io.h>

void *ioremap(unsigned long phys_addr, unsigned long size);

void *ioremap_nocache(unsigned long phys_addr, unsigned long size);在大多數計算機平台上，該函數和ioremap相同：當所有I/O內存已屬於非緩存地址時，就沒有必要實現ioremap的獨立的，非緩沖版本。

void iounmap(void *addr);

記住，由ioremap返回的地址不應該直接引用，而應該使用內核提供的accessor函數。

訪問I/O內存

在某些平台上我們可以將ioremap的返回值直接當作指針使用。但是，這種使用不具有可移植性，訪問I/O內存的正確方法是通過一組專用於些目的的函數(在<asm/io.h>中定義)。

從I/O內存中讀取，可使用以下函數之一：

unsigned int ioread8(void *addr);

unsigned int ioread16(void *addr);

unsigned int ioread32(void *addr);

其中，addr是從ioremap獲得的地址(可能包含一個整數偏移量);返回值是從給定I/O內存讀取到的值。

寫入I/O內存的函數如下：

void iowrite8(u8 value, void *addr);

void iowrite16(u16 value, void *addr);

void iowrite32(u32 value, void *addr);

如果必須在給定的I/O內存地址處讀/寫一系列值，則可使用上述函數的重復版本：

void ioread8_rep(void *addr, void *buf, unsigned long count);

void ioread16_rep(void *addr, void *buf, unsigned long count);

void ioread32_rep(void *addr, void *buf, unsigned long count);

void iowrite8_rep(void *addr, const void *buf, unsigned long count);

void iowrite16_rep(void *addr, const void *buf, unsigned long count);

void iowrite32_rep(void *addr, const void *buf, unsigned long count);

上述函數從給定的buf向給定的addr讀取或寫入count個值。count以被寫入數據的大小為單位。

上面函數均在給定的addr處執行所有的I/O操作，如果我們要在一塊I/O內存上執行操作，則可以使用下面的函數：

void memset_io(void *addr, u8 value, unsigned int count);

void memcpy_fromio(void *dest, void *source, unsigned int count);

void memcpy_toio(void *dest, void *source, unsigned int count);

上述函數和C函數庫的對應函數功能一致。

像I/O內存一樣使用I/O埠

某些硬體具有一種有趣的特性：某些版本使用I/O埠，而其他版本則使用I/O內存。導出給處理器的寄存器在兩種情況下都是一樣的，但訪問方法卻不同。為了讓處理這類硬體的驅動程序更加易於編寫，也為了最小化I/O埠和I/O內存訪問這間的表面區別，2.6內核引入了ioport_map函數：

void *ioport_map(unsigned long port, unsigned int count);

該函數重新映射count個I/O埠，使其看起來像I/O內存。此後，驅動程序可在該函數返回的地址上使用ioread8及其相關函數，這樣就不必理會I/O埠和I/O內存之間的區別了。

當不需要這種映射時使用下面函數一撤消：

void ioport_unmap(void *addr);

這些函數使得I/O埠看起來像內存。但需要注意的是，在重新映射之前，我們必須通過request_region來分配這些I/O埠。

為I/O內存重用short

前面介紹的short示例模塊訪問的是I/O埠，它也可以訪問I/O內存。為此必須在載入時通知它使用I/O內存，另外還要修改base地址以使其指向I/O區域。

下例是在MIPS開發板上點亮調試用的LED：

mips.root# ./short_load use_mem=1 base = 0xb7ffffc0

mips.root# echo -n 7 > /dev/short0

下面代碼是short寫入內存區域時使用的循環：

while(count--) {

iowrite8(*ptr++, address);

wmb();

}

1MB地址空間之下的ISA內存

最廣為人知的I/O內存區之一就是個人計算機上的ISA內存段。它的內存范圍在64KB(0xA0000)到1MB(0x100000)之間，因此它正好出現在常規系統RAM的中間。這種地址看上去有點奇怪，因為這個設計決策是20世紀80年代早期作出的，在當時看來沒有人會用到640KB以上的內存。

『叄』 什麼是全棧工程師

前端工程師：在打開一個網站時，屏幕上的一切都屬於前端。前端工程師負責創建用戶界面背後的代碼。這些工程師不僅要熟悉HTML、JavaScript與CSS，還要掌握很多框架。這些框架有Foundation、Angular JS、Ember JS、Backbone及Bootstrap等等。前端工程師要與設計師和其他專家協同工作，從而將網站從模型轉換為可使用的模式。

後端工程師：在你每天所訪問的網站背後有伺服器網路、資料庫以及各種應用，他們相互協作將你所請求的網頁與數據傳遞給你。後端工程師負責構建這些組件。他們要擅長各種編程語言，如Python、.Net、Ruby、Java及PHP等等，從而通過這些語言來編寫程序。他們還需要使用各種資料庫程序如MySQL、SQL Server及Oracle等來操縱信息並將其傳遞給最終用戶。後端工程師需要與組織中的各種經理及其他成員通力配合來完成工作。

全棧工程師：全棧工程師既要了解後端開發，也要了解前端開發。他們是「全方位」的工程師，熟悉服務端的同時又懂客戶端用戶體驗。全棧工程師理解Web開發進程的每一個方面，同時又會就整體策略與最佳實踐對相關干係人提出建議與指導。

『肆』 C語言中Valatile關鍵字有什麼用

volatile提醒編譯器它後面所定義的變數隨時都有可能改變，因此編譯後的程序每次需要存儲或讀取這個變數的時候，都會直接從變數地址中讀取數據。如果沒有volatile關鍵字，則編譯器可能優化讀取和存儲，可能暫時使用寄存器中的值，如果這個變數由別的程序更新了的話，將出現不一致的現象。下面舉例說明。在DSP開發中，經常需要等待某個事件的觸發，所以經常會寫出這樣的程序：
short flag;
void test()
{
do1();
while(flag==0);
do2();
}
這段程序等待內存變數flag的值變為1(懷疑此處是0,有點疑問,)之後才運行do2()。變數flag的值由別的程序更改，這個程序可能是某個硬體中斷服務程序。例如：如果某個按鈕按下的話，就會對DSP產生中斷，在按鍵中斷程序中修改flag為1，這樣上面的程序就能夠得以繼續運行。但是，編譯器並不知道flag的值會被別的程序修改，因此在它進行優化的時候，可能會把flag的值先讀入某個寄存器，然後等待那個寄存器變為1。如果不幸進行了這樣的優化，那麼while循環就變成了死循環，因為寄存器的內容不可能被中斷服務程序修改。為了讓程序每次都讀取真正flag變數的值，就需要定義為如下形式：
volatile short flag;
需要注意的是，沒有volatile也可能能正常運行，但是可能修改了編譯器的優化級別之後就又不能正常運行了。因此經常會出現debug版本正常，但是release版本卻不能正常的問題。所以為了安全起見，只要是等待別的程序修改某個變數的話，就加上volatile關鍵字。

volatile的本意是「易變的」
由於訪問寄存器的速度要快過RAM，所以編譯器一般都會作減少存取外部RAM的優化。比如：
static int i=0;
int main(void)
{
...
while (1)
{
if (i) do_something();
}
}
/* Interrupt service routine. */
void ISR_2(void)
{
i=1;
}
程序的本意是希望ISR_2中斷產生時，在main當中調用do_something函數，但是，由於編譯器判斷在main函數裡面沒有修改過i，因此可能只執行一次對從i到某寄存器的讀操作，然後每次if判斷都只使用這個寄存器裡面的「i副本」，導致do_something永遠也不會被調用。如果變數加上volatile修飾，則編譯器保證對此變數的讀寫操作都不會被優化（肯定執行）。此例中i也應該如此說明。
一般說來，volatile用在如下的幾個地方：
1、中斷服務程序中修改的供其它程序檢測的變數需要加volatile；
2、多任務環境下各任務間共享的標志應該加volatile；
3、存儲器映射的硬體寄存器通常也要加volatile說明，因為每次對它的讀寫都可能由不同意義；
另外，以上這幾種情況經常還要同時考慮數據的完整性（相互關聯的幾個標志讀了一半被打斷了重寫），在1中可以通過關中斷來實現，2中可以禁止任務調度，3中則只能依靠硬體的良好設計了。
二、volatile 的含義
volatile總是與優化有關，編譯器有一種技術叫做數據流分析，分析程序中的變數在哪裡賦值、在哪裡使用、在哪裡失效，分析結果可以用於常量合並，常量傳播等優化，進一步可以死代碼消除。但有時這些優化不是程序所需要的，這時可以用volatile關鍵字禁止做這些優化，volatile的字面含義是易變的，它有下面的作用：
1 不會在兩個操作之間把volatile變數緩存在寄存器中。在多任務、中斷、甚至setjmp環境下，變數可能被其他的程序改變，編譯器自己無法知道，volatile就是告訴編譯器這種情況。
2 不做常量合並、常量傳播等優化，所以像下面的代碼：
volatile int i = 1;
if (i > 0) ...
if的條件不會當作無條件真。
3 對volatile變數的讀寫不會被優化掉。如果你對一個變數賦值但後面沒用到，編譯器常常可以省略那個賦值操作，然而對Memory Mapped IO的處理是不能這樣優化的。
前面有人說volatile可以保證對內存操作的原子性，這種說法不大准確，其一，x86需要LOCK前綴才能在SMP下保證原子性，其二，RISC根本不能對內存直接運算，要保證原子性得用別的方法，如atomic_inc。
對於jiffies，它已經聲明為volatile變數，我認為直接用jiffies++就可以了，沒必要用那種復雜的形式，因為那樣也不能保證原子性。
你可能不知道在Pentium及後續CPU中，下面兩組指令
inc jiffies
;;
mov jiffies, %eax
inc %eax
mov %eax, jiffies
作用相同，但一條指令反而不如三條指令快。
三、編譯器優化 → C關鍵字volatile → memory破壞描述符zz
「memory」比較特殊，可能是內嵌匯編中最難懂部分。為解釋清楚它，先介紹一下編譯器的優化知識，再看C關鍵字volatile。最後去看該描述符。
1、編譯器優化介紹
內存訪問速度遠不及CPU處理速度，為提高機器整體性能，在硬體上引入硬體高速緩存Cache，加速對內存的訪問。另外在現代CPU中指令的執行並不一定嚴格按照順序執行，沒有相關性的指令可以亂序執行，以充分利用CPU的指令流水線，提高執行速度。以上是硬體級別的優化。再看軟體一級的優化：一種是在編寫代碼時由程序員優化，另一種是由編譯器進行優化。編譯器優化常用的方法有：將內存變數緩存到寄存器；調整指令順序充分利用CPU指令流水線，常見的是重新排序讀寫指令。對常規內存進行優化的時候，這些優化是透明的，而且效率很好。由編譯器優化或者硬體重新排序引起的問題的解決辦法是在從硬體（或者其他處理器）的角度看必須以特定順序執行的操作之間設置內存屏障（memory barrier），linux 提供了一個宏解決編譯器的執行順序問題。
void Barrier(void)
這個函數通知編譯器插入一個內存屏障，但對硬體無效，編譯後的代碼會把當前CPU寄存器中的所有修改過的數值存入內存，需要這些數據的時候再重新從內存中讀出。
2、C語言關鍵字volatile
C語言關鍵字volatile（注意它是用來修飾變數而不是上面介紹的__volatile__）表明某個變數的值可能在外部被改變，因此對這些變數的存取不能緩存到寄存器，每次使用時需要重新存取。該關鍵字在多線程環境下經常使用，因為在編寫多線程的程序時，同一個變數可能被多個線程修改，而程序通過該變數同步各個線程，例如：
DWORD __stdcall threadFunc(LPVOID signal)
{
int* intSignal=reinterpret_cast<int*>(signal);
*intSignal=2;
while(*intSignal!=1)
sleep(1000);
return 0;
}
該線程啟動時將intSignal 置為2，然後循環等待直到intSignal 為1 時退出。顯然intSignal的值必須在外部被改變，否則該線程不會退出。但是實際運行的時候該線程卻不會退出，即使在外部將它的值改為1，看一下對應的偽匯編代碼就明白了：
mov ax,signal
label:
if(ax!=1)
goto label
對於C編譯器來說，它並不知道這個值會被其他線程修改。自然就把它cache在寄存器裡面。記住，C 編譯器是沒有線程概念的！這時候就需要用到volatile。volatile 的本意是指：這個值可能會在當前線程外部被改變。也就是說，我們要在threadFunc中的intSignal前面加上volatile關鍵字，這時候，編譯器知道該變數的值會在外部改變，因此每次訪問該變數時會重新讀取，所作的循環變為如下面偽碼所示：
label:
mov ax,signal
if(ax!=1)
goto label
3、Memory
有了上面的知識就不難理解Memory修改描述符了，Memory描述符告知GCC：
1）不要將該段內嵌匯編指令與前面的指令重新排序；也就是在執行內嵌匯編代碼之前，它前面的指令都執行完畢
2）不要將變數緩存到寄存器，因為這段代碼可能會用到內存變數，而這些內存變數會以不可預知的方式發生改變，因此GCC插入必要的代碼先將緩存到寄存器的變數值寫回內存，如果後面又訪問這些變數，需要重新訪問內存。
如果匯編指令修改了內存，但是GCC 本身卻察覺不到，因為在輸出部分沒有描述，此時就需要在修改描述部分增加「memory」，告訴GCC 內存已經被修改，GCC 得知這個信息後，就會在這段指令之前，插入必要的指令將前面因為優化Cache 到寄存器中的變數值先寫回內存，如果以後又要使用這些變數再重新讀取。
使用「volatile」也可以達到這個目的，但是我們在每個變數前增加該關鍵字，不如使用「memory」方便。

『伍』 為什麼原子操作都起內存屏障的作用

(1) 進行零次或一次對齊內存訪問的匯編指令是原子的。

(2) 如果在讀操作之後、寫操作之前沒有其它處理器佔用內存匯流排，那麼從內存中讀取數據、更新數據並把更新後的數據寫回內存中的這些」 讀—修改—寫」匯編語言指令是原子的。當然，在單處理器系統中，永遠都不會發生內存匯流排竊用的情況。

(3) 操作碼前緣是lock位元組的」 讀—修改—寫」匯編語言指令即使在多處理器系統中也是原子的。當控制單元檢測到這個前綴時，就」鎖定」內存匯流排，直到這條指令執行完成為止。因此，當加鎖的指令執行時，其它處理器不能訪問這個內存單元。

(4) 操作碼前綴是一個rep位元組的匯編語言指令不是原子的，這條指令強行讓控制單元多次重復執行相同的指令。控制單元在執行新的循環之前要檢查掛起的中斷。

在你編寫C代碼程序時，並不能保證編譯器會為a=a+1或甚至像a++這樣的操作使用一個原子指令。因此，Linux內核提供了一個專門的atomic_c類型和一些專門的函數和宏(參見表5-4)，這些函數和宏作用於atomic_t類型的變數，並當作單獨的、原子的匯編語言指令來使用。在多處理器系統中，每條這樣的指令都有一個lock位元組的前綴。