原子變數linux
當多個進程同時訪問一個文件的時候，普通的write/read在執行的時候，無法保證操作的原子性，可能會導致文件被污染，達不到預期的結果。
任何一個需要多個函數調用的操作都不可能是原子操作，因為在兩個函數調用間，內核可能會將進程掛起執行另外的進程。
如果想要避免這種情況的話，則需要使用pread/pwrite函數
ssize_t pread(int fd ，void *buffer ，size_t size，off_t offset)
返回真正讀取到的位元組數，offset是指的從文件開始位置起的offset個位元組數開始讀。其餘的參數與read無異。
PS:
pread是無法中斷的原子操作，無法中斷它的定位和讀取操作
pread讀取過後的文件偏移量不會發生改變
同理pwrite也是一樣的
而在文件創建的時候也是一樣的，當需要做文件創建同步的時候，我們需要在O_CREATE的時候，加上O_EXCL標志位，當已經創建過的話，會返回fd，否則返回錯誤
int p( int filedes)：
傳入一個文件描述符，返回當前可用的最小文件描述符。
int p2(int filedes，int filedes2)：
傳入文件描述符，以及新的文件描述符，如果新的文件描述符所指向的文件已經打開，則會強行將其關閉後，將該文件描述符指向到已存在的文件描述符。
如果filedes和filedes2指向同一個文件，則不做任何處理，直接返回filedes2，不會關閉文件
新返回回來的filedes2會共享filedes的文件狀態標識，文件偏移量等等信息。因為它們的文件指針會指向文件表的同一個位置。只是fd不一樣而已。
Ⅱ Linux中的原子變數如何取地址，如何給定義的原子變數賦指定的地址
首先請確定你要做原子操作的對象是誰？是一個地址，還是地址指向的數據？
如果把數據做為原子對象，直接對數據進行原子操作即可，數據的指針不用做原子操作。
Ⅲ linux內核同步問題
Linux內核設計與實現 十、內核同步方法
手把手教Linux驅動5-自旋鎖、信號量、互斥體概述
== 基礎概念： ==
並發 ：多個執行單元同時進行或多個執行單元微觀串列執行，宏觀並行執行
競態 ：並發的執行單元對共享資源（硬體資源和軟體上的全局變數）的訪問而導致的竟態狀態。
臨界資源 ：多個進程訪問的資源
臨界區 ：多個進程訪問的代碼段
== 並發場合： ==
1、單CPU之間進程間的並發 :時間片輪轉，調度進程。 A進程訪問列印機，時間片用完，OS調度B進程訪問列印機。
2、單cpu上進程和中斷之間並發 ：CPU必須停止當前進程的執行中斷;
3、多cpu之間
4、單CPU上中斷之間的並發
== 使用偏向： ==
==信號量用於進程之間的同步，進程在信號量保護的臨界區代碼裡面是可以睡眠的（需要進行進程調度），這是與自旋鎖最大的區別。==
信號量又稱為信號燈，它是用來協調不同進程間的數據對象的，而最主要的應用是共享內存方式的進程間通信。本質上，信號量是一個計數器，它用來記錄對某個資源（如共享內存）的存取狀況。它負責協調各個進程，以保證他們能夠正確、合理的使用公共資源。它和spin lock最大的不同之處就是：無法獲取信號量的進程可以睡眠，因此會導致系統調度。
1、==用於進程與進程之間的同步==
2、==允許多個進程進入臨界區代碼執行，臨界區代碼允許睡眠；==
3、信號量本質是==基於調度器的==，在UP和SMP下沒有區別；進程獲取不到信號量將陷入休眠，並讓出CPU；
4、不支持進程和中斷之間的同步
5、==進程調度也是會消耗系統資源的，如果一個int型共享變數就需要使用信號量，將極大的浪費系統資源==
6、信號量可以用於多個線程，用於資源的計數（有多種狀態）
==信號量加鎖以及解鎖過程：==
sema_init(&sp->dead_sem, 0); / 初始化 /
down(&sema);
臨界區代碼
up(&sema);
==信號量定義：==
==信號量初始化：==
==dowm函數實現：==
==up函數實現：==
信號量一般可以用來標記可用資源的個數。
舉2個生活中的例子：
==dowm函數實現原理解析：==
（1）down
判斷sem->count是否 > 0，大於0則說明系統資源夠用，分配一個給該進程，否則進入__down(sem);
（2）__down
調用__down_common(sem, TASK_UNINTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT);其中TASK_UNINTERRUPTIBLE=2代表進入睡眠，且不可以打斷；MAX_SCHEDULE_TIMEOUT休眠最長LONG_MAX時間；
（3）list_add_tail(&waiter.list, &sem->wait_list);
把當前進程加入到sem->wait_list中；
（3）先解鎖後加鎖;
進入__down_common前已經加鎖了，先把解鎖，調用schele_timeout(timeout)，當waiter.up=1後跳出for循環；退出函數之前再加鎖；
Linux內核ARM構架中原子變數的底層實現研究
rk3288 原子操作和原子位操作
原子變數適用於只共享一個int型變數；
1、原子操作是指不被打斷的操作，即它是最小的執行單位。
2、最簡單的原子操作就是一條條的匯編指令(不包括一些偽指令，偽指令會被匯編器解釋成多條匯編指令)
==常見函數：==
==以atomic_inc為例介紹實現過程==
在Linux內核文件archarmincludeasmatomic.h中。 執行atomic_read、atomic_set這些操作都只需要一條匯編指令，所以它們本身就是不可打斷的。 需要特別研究的是atomic_inc、atomic_dec這類讀出、修改、寫回的函數。
所以atomic_add的原型是下面這個宏：
atomic_add等效於：
result（%0） tmp（%1） (v->counter)（%2） (&v->counter)（%3） i（%4）
注意：根據內聯匯編的語法，result、tmp、&v->counter對應的數據都放在了寄存器中操作。如果出現上下文切換，切換機制會做寄存器上下文保護。
（1）ldrex %0, [%3]
意思是將&v->counter指向的數據放入result中，並且（分別在Local monitor和Global monitor中）設置獨占標志。
（2）add %0, %0, %4
result = result + i
（3）strex %1, %0, [%3]
意思是將result保存到&v->counter指向的內存中， 此時 Exclusive monitors會發揮作用，將保存是否成功的標志放入tmp中。
（4） teq %1, #0
測試strex是否成功（tmp == 0 ？？）
（5）bne 1b
如果發現strex失敗，從（1）再次執行。
Spinlock 是內核中提供的一種比較常見的鎖機制，==自旋鎖是「原地等待」的方式解決資源沖突的==，即，一個線程獲取了一個自旋鎖後，另外一個線程期望獲取該自旋鎖，獲取不到，只能夠原地「打轉」（忙等待）。由於自旋鎖的這個忙等待的特性，註定了它使用場景上的限制 —— 自旋鎖不應該被長時間的持有（消耗 CPU 資源），一般應用在==中斷上下文==。
1、spinlock是一種死等機制
2、信號量可以允許多個執行單元進入，spinlock不行，一次只能允許一個執行單元獲取鎖，並且進入臨界區，其他執行單元都是在門口不斷的死等
3、由於不休眠，因此spinlock可以應用在中斷上下文中；
4、由於spinlock死等的特性，因此臨界區執行代碼盡可能的短；
==spinlock加鎖以及解鎖過程：==
spin_lock(&devices_lock);
臨界區代碼
spin_unlock(&devices_lock);
==spinlock初始化==
==進程和進程之間同步==
==本地軟中斷之間同步==
==本地硬中斷之間同步==
==本地硬中斷之間同步並且保存本地中斷狀態==
==嘗試獲取鎖==
== arch_spinlock_t結構體定義如下： ==
== arch_spin_lock的實現如下： ==
lockval（%0） newval（%1） tmp（%2） &lock->slock（%3） 1 << TICKET_SHIFT（%4）
（1）ldrex %0, [%3]
把lock->slock的值賦值給lockval；並且（分別在Local monitor和Global monitor中）設置獨占標志。
（2）add %1, %0, %4
newval =lockval +（1<<16）; 相當於next+1；
（3）strex %2, %1, [%3]
newval =lockval +（1<<16）; 相當於next+1；
意思是將newval保存到 &lock->slock指向的內存中， 此時 Exclusive monitors會發揮作用，將保存是否成功的標志放入tmp中。
（4） teq %2, #0
測試strex是否成功
（5）bne 1b
如果發現strex失敗，從（1）再次執行。
通過上面的分析，可知關鍵在於strex的操作是否成功的判斷上。而這個就歸功於ARM的Exclusive monitors和ldrex/strex指令的機制。
（6）while (lockval.tickets.next != lockval.tickets.owner)
如何lockval.tickets的next和owner是否相等。相同則跳出while循環，否則在循環內等待判斷；
* （7）wfe()和smp_mb() 最終調用#define barrier() asm volatile ("": : :"memory") *
阻止編譯器重排，保證編譯程序時在優化屏障之前的指令不會在優化屏障之後執行。
== arch_spin_unlock的實現如下： ==
退出鎖時：tickets.owner++
== 出現死鎖的情況： ==
1、擁有自旋鎖的進程A在內核態阻塞了，內核調度B進程，碰巧B進程也要獲得自旋鎖，此時B只能自旋轉。 而此時搶占已經關閉，（單核）不會調度A進程了，B永遠自旋，產生死鎖。
2、進程A擁有自旋鎖，中斷到來，CPU執行中斷函數，中斷處理函數，中斷處理函數需要獲得自旋鎖，訪問共享資源，此時無法獲得鎖，只能自旋，產生死鎖。
== 如何避免死鎖： ==
1、如果中斷處理函數中也要獲得自旋鎖，那麼驅動程序需要在擁有自旋鎖時禁止中斷；
2、自旋鎖必須在可能的最短時間內擁有
3、避免某個獲得鎖的函數調用其他同樣試圖獲取這個鎖的函數，否則代碼就會死鎖；不論是信號量還是自旋鎖，都不允許鎖擁有者第二次獲得這個鎖，如果試圖這么做，系統將掛起；
4、鎖的順序規則（a) 按同樣的順序獲得鎖；b) 如果必須獲得一個局部鎖和一個屬於內核更中心位置的鎖，則應該首先獲取自己的局部鎖 ;c) 如果我們擁有信號量和自旋鎖的組合，則必須首先獲得信號量；在擁有自旋鎖時調用down(可導致休眠)是個嚴重的錯誤的；）
== rw（read/write）spinlock： ==
加鎖邏輯：
1、假設臨界區內沒有任何的thread，這個時候任何的讀線程和寫線程都可以鍵入
2、假設臨界區內有一個讀線程，這時候信賴的read線程可以任意進入，但是寫線程不能進入；
3、假設臨界區有一個寫線程，這時候任何的讀、寫線程都不可以進入；
4、假設臨界區內有一個或者多個讀線程，寫線程不可以進入臨界區，但是寫線程也無法阻止後續的讀線程繼續進去，要等到臨界區所有的讀線程都結束了，才可以進入，可見：==rw（read/write）spinlock更加有利於讀線程；==
== seqlock（順序鎖）： ==
加鎖邏輯：
1、假設臨界區內沒有任何的thread，這個時候任何的讀線程和寫線程都可以鍵入
2、假設臨界區內沒有寫線程的情況下，read線程可以任意進入；
3、假設臨界區有一個寫線程，這時候任何的讀、寫線程都不可以進入；
4、假設臨界區內只有read線程的情況下，寫線程可以理解執行，不會等待，可見：==seqlock（順序鎖）更加有利於寫線程；==
讀寫速度 ： CPU > 一級緩存 > 二級緩存 > 內存 ，因此某一個CPU0的lock修改了，其他的CPU的lock就會失效；那麼其他CPU就會依次去L1 L2和主存中讀取lock值，一旦其他CPU去讀取了主存，就存在系統性能降低的風險；
mutex用於互斥操作。
互斥體只能用於一個線程，資源只有兩種狀態（佔用或者空閑）
1、mutex的語義相對於信號量要簡單輕便一些，在鎖爭用激烈的測試場景下，mutex比信號量執行速度更快，可擴展
性更好，
2、另外mutex數據結構的定義比信號量小;、
3、同一時刻只有一個線程可以持有mutex
4、不允許遞歸地加鎖和解鎖
5、當進程持有mutex時，進程不可以退出。
• mutex必須使用官方API來初始化。
• mutex可以睡眠，所以不允許在中斷處理程序或者中斷下半部中使用，例如tasklet、定時器等
==常見操作：==
struct mutex mutex_1;
mutex_init(&mutex_1);
mutex_lock(&mutex_1)
臨界區代碼；
mutex_unlock(&mutex_1)
==常見函數：==
=
Ⅳ Linux上有哪些操作是原子操作
所謂原子操作，就是該操作絕不會在執行完畢前被任何其他任務或事件打斷，也就說，它的最小的執行單位，不可能有比它更小的執行單位，因此這里的原子實際是使用了物理學里的物質微粒的概念。
原子操作通常用於實現資源的引用計數，在TCP/IP協議棧的IP碎片處理中，就使用了引用計數，碎片隊列結構struct ipq描述了一個IP碎片，欄位refcnt就是引用計數器，它的類型為atomic_t，當創建IP碎片時（在函數ip_frag_create中），使用atomic_set函數把它設置為1，當引用該IP碎片時，就使用函數atomic_inc把引用計數加1。
當不需要引用該IP碎片時，就使用函數ipq_put來釋放該IP碎片，ipq_put使用函數atomic_dec_and_test把引用計數減1並判斷引用計數是否為0，如果是就釋放IP碎片。函數ipq_kill把IP碎片從ipq隊列中刪除，並把該刪除的IP碎片的引用計數減1（通過使用函數atomic_dec實現）。
Ⅳ linux 2.6內核有關原子變數的定義問題
原子意味著不可分割，所謂原子操作就是對變數的讀寫不能被打斷的操作。
舉個簡單點兒的例子：
1. 假如在一個i386體系架構上；
2. 如果有一個進程要將一個int型的變數改成0x12345678；
3. 另一個進程也希望把這同一個變數改成0x87654321。
4. 如果這個變數的地址沒有4位元組對齊，那麼cpu要改寫它的值的話需要兩次匯流排操作。
那麼（假設下面的場景，即下列事件先後發生）：
1. 第一個進程剛把高位元組寫入（x=0x1234xxxx）內存（xxxx表示不確定）；
2. 第二進程就搶佔了第一個進程的運行，把第一個進程改了一半的變數改成0x87654321。（當然他也需要兩次匯流排操作，但我們假設他的優先順序比第一個進程高）
3. 第二個進程結束運行後，第一個進程又得到了調度，它並不知道自己對變數的操作被另一個進程打斷過，所以他會繼續更改變數的低位元組。
所以，最後這個變數的值就是0x87655678，顯然這是兩個進程都不想要得到的結果。通過上面的分析你應該知道問題的關鍵就在於對存儲空間的訪問被打斷了造成的。所以在內核中定義了一系列的原子操作來保證對變數的操作是「原子」的。這種互斥不是高級語言能實現的，必須用匯編，而且依賴於體系架構。對i386來說就是在讀寫變數的時候先把匯流排鎖住，你可以仔細看看ATOMIC_INIT這個宏的定義。
Ⅵ linux原子操作和自旋鎖的區別
現代操作系統支持多任務的並發，並發在提高計算資源利用率的同時也帶來了資源競爭的問題。例如C語言語句「count++;」在未經編譯器優化時生成的匯編代碼為。
當操作系統內存在多個進程同時執行這段代碼時，就可能帶來並發問題。
假設count變數初始值為0。進程1執行完「mov eax, [count]」後，寄存器eax內保存了count的值0。此時，進程2被調度執行，搶佔了進程1的CPU的控制權。進程2執行「count++;」的匯編代碼，將累加後的count值1寫回到內存。然後，進程1再次被調度執行，CPU控制權回到進程1。進程1接著執行，計算count的累加值仍為1，寫回到內存。雖然進程1和進程2執行了兩次「count++;」操作，但是count實際的內存值為1，而不是2！
單處理器原子操作
解決這個問題的方法是，將「count++;」語句翻譯為單指令操作。
Intel x86指令集支持內存操作數的inc操作，這樣「count++;」操作可以在一條指令內完成。因為進程的上下文切換是在總是在一條指令執行完成後，所以不會出現上述的並發問題。對於單處理器來說，一條處理器指令就是一個原子操作。
多處理器原子操作
但是在多處理器的環境下，例如SMP架構，這個結論不再成立。我們知道「inc [count]」指令的執行過程分為三步：
1）從內存將count的數據讀取到cpu。
2）累加讀取的值。
3）將修改的值寫回count內存。
這又回到前面並發問題類似的情況，只不過此時並發的主題不再是進程，而是處理器。
Intel x86指令集提供了指令前綴lock用於鎖定前端串列匯流排（FSB），保證了指令執行時不會受到其他處理器的干擾。
使用lock指令前綴後，處理器間對count內存的並發訪問（讀/寫）被禁止，從而保證了指令的原子性。
x86原子操作實現
Linux的源碼中x86體系結構原子操作的定義文件為。
linux2.6/include/asm-i386/atomic.h
文件內定義了原子類型atomic_t，其僅有一個欄位counter，用於保存32位的數據。
typedef struct { volatile int counter; } atomic_t;
其中原子操作函數atomic_inc完成自加原子操作。
/**
* atomic_inc - increment atomic variable
* @v: pointer of type atomic_t
*
* Atomically increments @v by 1.
*/
static __inline__ void atomic_inc(atomic_t *v)
{
__asm__ __volatile__(
LOCK "incl %0"
:"=m" (v->counter)
:"m" (v->counter));
}
其中LOCK宏的定義為。
#ifdef CONFIG_SMP
#define LOCK "lock ; "
#else
#define LOCK ""
#endif
可見，在對稱多處理器架構的情況下，LOCK被解釋為指令前綴lock。而對於單處理器架構，LOCK不包含任何內容。
arm原子操作實現
在arm的指令集中，不存在指令前綴lock，那如何完成原子操作呢？
Linux的源碼中arm體系結構原子操作的定義文件為。
linux2.6/include/asm-arm/atomic.h
其中自加原子操作由函數atomic_add_return實現。
static inline int atomic_add_return(int i, atomic_t *v)
{
unsigned long tmp;
int result;
__asm__ __volatile__("@ atomic_add_return\n"
"1: ldrex %0, [%2]\n"
" add %0, %0, %3\n"
" strex %1, %0, [%2]\n"
" teq %1, #0\n"
" bne 1b"
: "=&r" (result), "=&r" (tmp)
: "r" (&v->counter), "Ir" (i)
: "cc");
return result;
}
上述嵌入式匯編的實際形式為。
1:
ldrex [result], [v->counter]
add [result], [result], [i]
strex [temp], [result], [v->counter]
teq [temp], #0
bne 1b
ldrex指令將v->counter的值傳送到result，並設置全局標記「Exclusive」。
add指令完成「result+i」的操作，並將加法結果保存到result。
strex指令首先檢測全局標記「Exclusive」是否存在，如果存在，則將result的值寫回counter->v，並將temp置為0，清除「Exclusive」標記，否則直接將temp置為1結束。
teq指令測試temp值是否為0。
bne指令temp不等於0時跳轉到標號1，其中字元b表示向後跳轉。
整體看來，上述匯編代碼一直嘗試完成「v->counter+=i」的操作，直到temp為0時結束。
使用ldrex和strex指令對是否可以保證add指令的原子性呢？假設兩個進程並發執行「ldrex+add+strex」操作，當進程1執行ldrex後設定了全局標記「Exclusive」。此時切換到進程2，執行ldrex前全局標記「Exclusive」已經設定，ldrex執行後重復設定了該標記。然後執行add和strex指令，完成累加操作。再次切換回進程1，接著執行add指令，當執行strex指令時，由於「Exclusive」標記被進程2清除，因此不執行傳送操作，將temp設置為1。後繼teq指令測定temp不等於0，則跳轉到起始位置重新執行，最終完成累加操作！可見ldrex和strex指令對可以保證進程間的同步。多處理器的情況與此相同，因為arm的原子操作只關心「Exclusive」標記，而不在乎前端串列匯流排是否加鎖。
在ARMv6之前，swp指令就是通過鎖定匯流排的方式完成原子的數據交換，但是影響系統性能。ARMv6之後，一般使用ldrex和strex指令對代替swp指令的功能。
自旋鎖中的原子操作
Linux的源碼中x86體系結構自旋鎖的定義文件為。
linux2.6/include/asm-i386/spinlock.h
其中__raw_spin_lock完成自旋鎖的加鎖功能
#define __raw_spin_lock_string \
"\n1:\t" \
"lock ; decb %0\n\t" \
"jns 3f\n" \
"2:\t" \
"rep;nop\n\t" \
"cmpb $0,%0\n\t" \
"jle 2b\n\t" \
"jmp 1b\n" \
"3:\n\t"
static inline void __raw_spin_lock(raw_spinlock_t *lock)
{
__asm__ __volatile__(
__raw_spin_lock_string
:"=m" (lock->slock) : : "memory");
}
上述代碼的實際匯編形式為。
1：
lock decb [lock->slock]
jns 3
2:
rep nop
cmpb $0, [lock->slock]
jle 2
jmp 1
3:
其中lock->slock欄位初始值為1，執行原子操作decb後值為0。符號位為0，執行jns指令跳轉到3，完成自旋鎖的加鎖。
當再次申請自旋鎖時，執行原子操作decb後lock->slock值為-1。符號位為1，不執行jns指令。進入標簽2，執行一組nop指令後比較lock->slock是否小於等於0，如果小於等於0回到標簽2進行循環（自旋）。否則跳轉到標簽1重新申請自旋鎖，直到申請成功。
自旋鎖釋放時會將lock->slock設置為1，這樣保證了其他進程可以獲得自旋鎖。
信號量中的原子操作
Linux的源碼中x86體系結構自旋鎖的定義文件為。
linux2.6/include/asm-i386/semaphore.h
信號量的申請操作由函數down實現。
/*
* This is ugly, but we want the default case to fall through.
* "__down_failed" is a special asm handler that calls the C
* routine that actually waits. See arch/i386/kernel/semaphore.c
*/
static inline void down(struct semaphore * sem)
{
might_sleep();
__asm__ __volatile__(
"# atomic down operation\n\t"
LOCK "decl %0\n\t" /* --sem->count */
"js 2f\n"
"1:\n"
LOCK_SECTION_START("")
"2:\tlea %0,%%eax\n\t"
"call __down_failed\n\t"
"jmp 1b\n"
LOCK_SECTION_END
:"=m" (sem->count)
:
:"memory","ax");
}
實際的匯編代碼形式為。
lock decl [sem->count]
js 2
1:
<========== another section ==========>
2:
lea [sem->count], eax
call __down_failed
jmp 1
信號量的sem->count一般初始化為一個正整數，申請信號量時執行原子操作decl，將sem->count減1。如果該值減為負數（符號位為1）則跳轉到另一個段內的標簽2，否則申請信號量成功。
標簽2被編譯到另一個段內，進入標簽2後，執行lea指令取出sem->count的地址，放到eax寄存器作為參數，然後調用函數__down_failed表示信號量申請失敗，進程加入等待隊列。最後跳回標簽1結束信號量申請。
信號量的釋放操作由函數up實現。
/*
* Note! This is subtle. We jump to wake people up only if
* the semaphore was negative (== somebody was waiting on it).
* The default case (no contention) will result in NO
* jumps for both down() and up().
*/
static inline void up(struct semaphore * sem)
{
__asm__ __volatile__(
"# atomic up operation\n\t"
LOCK "incl %0\n\t" /* ++sem->count */
"jle 2f\n"
"1:\n"
LOCK_SECTION_START("")
"2:\tlea %0,%%eax\n\t"
"call __up_wakeup\n\t"
"jmp 1b\n"
LOCK_SECTION_END
".subsection 0\n"
:"=m" (sem->count)
:
:"memory","ax");
}
實際的匯編代碼形式為。
lock incl sem->count
jle 2
1:
<========== another section ==========>
2:
lea [sem->count], eax
call __up_wakeup
jmp 1
釋放信號量時執行原子操作incl將sem->count加1，如果該值小於等於0，則說明等待隊列有阻塞的進程需要喚醒，跳轉到標簽2，否則信號量釋放成功。
標簽2被編譯到另一個段內，進入標簽2後，執行lea指令取出sem->count的地址，放到eax寄存器作為參數，然後調用函數__up_wakeup喚醒等待隊列的進程。最後跳回標簽1結束信號量釋放。