ksearch系統中有兩個角色會共享數據：searcher和updater，searcher是多線程讀，對外提供檢索服務；updater是單線程，對外提供更新服務。searcher和updater是一臺機器上的兩個獨立進程，通過共享內存實現數據共享。searcher可以看到兩份數據，一份是全量數據，以類似數組的形式組織數據；一份是增量數據，由updater進程提供，以單鏈表的形式組織數據。爲了防止更新加鎖，影響讀取的性能，我們在searcher和updater之間使用了一種無鎖的機制。
我們使用了lease機制來實現無鎖。具體做法是，在增量doc的數據結構上添加了2個字段，一個時間字段，用來記錄該條doc從鏈表中刪除的時間；一個lease指針，維護刪除的doc鏈表。當有一個更新操作過來，從單鏈表中找到原有記錄（爲了加速查找，單鏈表是經過排序的，而且加了跳錶結構），把它添加到lease鏈表尾部，重置時間字段爲當前，但是不改變原有的增量單鏈表結構；然後找一個空閒doc，做更新操作，然後加入到增量單鏈表結構中（原記錄所在位置）。這樣即使search在讀過程中，doc發生了更新，search要麼拿到更新前的doc，要麼拿到更新後的doc，由於更新前後增量鏈表都是完成的，所以不會影響search的讀。同時由於search的單個query處理時間一般在1s之內，我們爲lease鏈表設置了一個過期時間，比如10s，保證所有還在使用lease鏈表中doc的search線程都已經結束。這樣更新取空閒doc的時候，可以先檢查lease鏈表的頭部doc，是否已過lease時間，過的話就可以拿出來安全使用。
在上述的方案中，我們認爲，單鏈表的操作過程（指針賦值）是原子的。即64位機器，指針是8字節，不會出現低32位完成了賦值，高32位還沒賦值就被CS走了的情況；如果在中間被CS走了，就會出現指針錯亂，是不可承受的。我們做了簡單的實驗，查看彙編代碼，可以看到指針賦值有二條指令，先把源指針mov到寄存器，再把寄存器mov到目標指針。CPU的一條指令是原子的，所以指針賦值不會錯亂。從實驗來看，不管目標指針，有沒有64位對齊，都是原子的；確切的，不是說指針賦值是原子的，而且目標指針要麼是新值要麼是老值，不會出現錯亂;爲安全起見，在實際應用中，我們要求鏈表指針按照8字節對齊。
發現一個問題： int64_t value = 0x1111111122222222，這個賦值是高32位和低32位分成兩個指令做的；int64_t value = other 這個是原子的。
這篇文章可以作爲很好的參考：http://blog.csdn.net/gantleman/article/details/6254266
多線程程序中操作的原子性
0. 背景
原子操作就是不可再分的操作。在多線程程序中原子操作是一個非常重要的概念，它常常用來實現一些同步機制，同時也是一些常見的多線程Bug的源頭。本文主要討論了三個問題：1. 多線程程序中對變量的讀寫操作是否是原子的？2. 多線程程序中對Bit field（位域）的讀寫操作是否是線程安全的？3. 程序員該如何使用原子操作？
1. 多線程環境下對變量的讀寫操作是否是原子的？
我們先從一道很熱門的百度筆試題講起。很多人講不清楚其背後的原理，下面我們就來對它進行一下剖析（其實這個題目有點歧義，後面我們會講到）：
以下多線程對int型變量x的操作，哪幾個需要進行同步：（ ）
A. x=y; B. x++; C. ++x; D. x=1;
要徹底理解這個問題，我們首先需要從硬件講起。以常見的X86 CPU來說，根據Intel的參考手冊，它基於以下三種機制保證了多核中加鎖的原子操作（8.1節）：
（1）Guaranteed atomic operations （注：8.1.1節有詳細介紹）
（2）Bus locking, using the LOCK# signal and the LOCK instruction prefix
（3）Cache coherency protocols that ensure that atomic operations can be carried out on cached data structures (cache lock); this mechanism is present in the Pentium 4, Intel Xeon, and P6 family processors
這三個機制相互獨立，相輔相承。簡單的理解起來就是
（1）一些基本的內存讀寫操作是本身已經被硬件提供了原子性保證（例如讀寫單個字節的操作）；
（2）一些需要保證原子性但是沒有被第（1）條機制提供支持的操作（例如read-modify-write）可以通過使用”LOCK#”來鎖定總線，從而保證操作的原子性
（3）因爲很多內存數據是已經存放在L1/L2 cache中了，對這些數據的原子操作只需要與本地的cache打交道，而不需要與總線打交道，所以CPU就提供了cache coherency機制來保證其它的那些也cache了這些數據的processor能讀到最新的值（關於cache coherency可以參加我的一篇博文）。
那麼CPU對哪些（1）中的基本的操作提供了原子性支持呢？根據Intel手冊8.1.1節的介紹：
從Intel486 processor開始，以下的基本內存操作是原子的：
• Reading or writing a byte（一個字節的讀寫）
• Reading or writing a word aligned on a 16-bit boundary（對齊到16位邊界的字的讀寫）
• Reading or writing a doubleword aligned on a 32-bit boundary（對齊到32位邊界的雙字的讀寫）
從Pentium processor開始，除了之前支持的原子操作外又新增了以下原子操作：
• Reading or writing a quadword aligned on a 64-bit boundary（對齊到64位邊界的四字的讀寫）
• 16-bit accesses to uncached memory locations that fit within a 32-bit data bus（未緩存且在32位數據總線範圍之內的內存地址的訪問）
從P6 family processors開始，除了之前支持的原子操作又新增了以下原子操作：
• Unaligned 16-, 32-, and 64-bit accesses to cached memory that fit within a cache line（對單個cache line中緩存地址的未對齊的16/32/64位訪問）
那麼哪些操作是非原子的呢？
Accesses to cacheable memory that are split across bus widths, cache lines, and
page boundaries are not guaranteed to be atomic by the Intel Core 2 Duo, Intel®
Atom™, Intel Core Duo, Pentium M, Pentium 4, Intel Xeon, P6 family, Pentium, and
Intel486 processors.（說點簡單點，那些被總線帶寬、cache line以及page大小給分隔開了的內存地址的訪問不是原子的，你如果想保證這些操作是原子的，你就得求助於機制（2），對總線發出相應的控制信號才行）。
需要注意的是儘管從P6 family開始對一些非對齊的讀寫操作已經提供了原子性保障，但是非對齊訪問是非常影響性能的，需要儘量避免。當然了，對於一般的程序員來說不需要太擔心這個，因爲大部分編譯器會自動幫你完成內存對齊。
回到最開始那個筆試題。我們先反彙編一下看看它們到底執行了什麼操作：
x = y;
mov eax,dword ptr [y]
mov dword ptr [x],eax
x++;
mov eax,dword ptr [x]
add eax,1
mov dword ptr [x],eax
++x;
mov eax,dword ptr [x]
add eax,1
mov dword ptr [x],eax
x = 1;
mov dword ptr [x],1
（1）很顯然，x=1是原子操作。
因爲x是int類型，32位CPU上int佔32位，在X86上由硬件直接提供了原子性支持。實際上不管有多少個線程同時執行類似x=1這樣的賦值語句，x的值最終還是被賦的值（而不會出現例如某個線程只更新了x的低16位然後被阻塞，另一個線程緊接着又更新了x的低24位然後又被阻塞，從而出現x的值被損壞了的情況）。
（2）再來看x++和++x。
其實類似x++, x+=2, ++x這樣的操作在多線程環境下是需要同步的。因爲X86會按三條指令的形式來處理這種語句：從內存中讀x的值到寄存器中，對寄存器加1，再把新值寫回x所處的內存地址（見上面的反彙編代碼）。
例如有兩個線程，它們按照如下順序執行（注意讀x和寫回x是原子操作，兩個線程不能同時執行）：
time Thread 1 Thread 2
0 load eax, x
1 load eax, x
2 add eax, 1 add eax, 1
3 store x, eax
4 store x, eax
我們會發現最終x的值會是1而不是2，因爲Thread 1的結果被覆蓋掉了。這種情況下我們就需要對x++這樣的操作加鎖（例如Pthread中的mutex）以保證同步，或者使用一些提供了atomic operations的庫（例如Windows API中的atomic庫，Linux內核中的atomic.h，Java concurrent庫中的Atomic Integer，C++0x中即將支持的atomic_int等等，這些庫會利用CPU提供的硬件機制做一層封裝，提供一些保證了原子性的API）。
（3）最後來看看x=y。
在X86上它包含兩個操作：讀取y至寄存器，再把該值寫入x。讀y的值這個操作本身是原子的，把值寫入x也是原子的，但是兩者合起來是不是原子操作呢？我個人認爲x=y不是原子操作，因爲它不是不可再分的操作。但是它需要不需要同步呢？其實問題的關鍵在於程序的上下文。
例如有兩個線程，線程1要執行{y = 1; x = y;}，線程2要執行{y = 2; y = 3;}，假設它們按如下時間順序執行：
time Thread 1 Thread 2
0 store y, 1
1 store y, 2
2 load eax, y
3 store y, 3
4 store x, eax
那麼最終線程1中x的值爲2，而不是它原本想要的1。我們需要加上相應的同步語句確保y = 2不會在線程1的兩條語句之間發生。y = 3那條語句儘管在load y和store x之間執行，但是卻不影響x=y這條語句本身的語義。所以你可以說x=y需要同步，也可以說x=y不需要同步，看你怎麼理解題意了。x=1是否需要同步也是一樣的道理，雖然它本身是原子操作，但是如果有另一個線程要讀x=1之後的值，那肯定也需要同步，否則另一個線程讀到的就是x的舊值而不是1了。
2. 對Bit field（位域）的讀寫操作是否是線程安全的？
Bit field常用來高效的存儲有限位數的變量，多用於內核/底層開發中。一般來說，對同一個結構體內的不同bit成員的多線程訪問是無法保證線程安全的。
例如Wikipedia中的如下例子：
struct foo {
int flag : 1;
int counter : 15;
};
struct foo my_foo;
/* ... */
/* in thread 1 */
pthread_mutex_lock(&my_mutex_for_flag);
my_foo.flag = !my_foo.flag;
pthread_mutex_unlock(&my_mutex_for_flag);
/* in thread 2 */
pthread_mutex_lock(&my_mutex_for_counter);
++my_foo.counter;
pthread_mutex_unlock(&my_mutex_for_counter);
兩個線程分別對my_foo.flag和my_foo.counter進行讀寫操作，但是即使有上面的加鎖方式仍然不能保證它是線程安全的。原因在於不同的成員在內存中的具體排列方式“跟Byte Order、Bit Order、對齊等問題都有關，不同的平臺和編譯器可能會排列得很不一樣，要編寫可移植的代碼就不能假定Bit-field是按某一種固定方式排列的”[3]。而且一般來講CPU對內存操作的最小單位是word（X86的word是16bits），而不是1bit。這就是說，如果my_foo.flag和my_foo.counter存儲在同一個word裏，CPU在讀寫任何一個bit member的時候會同時把兩個值一起讀進寄存器，從而造成讀寫衝突。這個例子正確的處理方式是用一個mutex同時保護my_foo.flag和my_foo.counter，這樣才能確保讀寫是線程安全的。
在C++0x草案中對bit field是這樣定義的：
連續的多個非0bit的bit fields是屬於同一個memory location的；長度爲0bit的bit field會把佔單獨的一個memory location。對同一個memory location的讀寫不是線程安全的；對不同memory location的讀寫是線程安全的。
例如在下圖的例子中bf1和bf2是同一個memory location，bf3是一個單獨的memory location，bf4是一個單獨的memory location：
這裏有一個因爲Bit field不是線程安全所導致的一個Linux內核中的Bug。
引用一下Pongba的總結：
所以，如果你的多個bitfields是連續的，同時又想要無衝突的讀取它們，有兩種做法，一是在中間用0大小bitfield隔開，但這種做法實際上就消除了bitfield的節省內存的初衷，因爲爲了使它們不衝突，至少被隔開的兩個bitfield肯定不可能共享byte了。另一種做法當然就是用鎖了。
3. 程序員該怎麼用Atomic操作？
一般情況下程序員不需要跟CPU提供的原子操作直接打交道，所以只需要選擇語言或者平臺提供的atomic API即可。而且使用封裝好了的API還有一個好處是它們常常還提供了諸如compare_and_swap，fetch_and_add這樣既有讀又有寫的較複雜操作的封裝。
常見的API如下：
Windows上InterlockedXXXX的API
GNU/Linux上linux kernel中atomic_32.h
GCC中的Atomic Builtins (__sync_fetch_and_add()等)
Java中的java.util.concurrent.atomic
C++0x中的atomic operation
Intel TBB中的atomic operation
4. 參考文獻：
[1] 關於變量操作的原子性(atomicity)FAQ
[2] http://en.wikipedia.org/wiki/Atomic_operation
[3] 關於內存對齊、bit field等 –《Linux C編程一站式學習》
[4] Do you need mutex to protect an ‘int’?
[5] C++ Concurrency in Action
[6] Multithreaded simple data type access and atomic variables
[6] http://www.newsmth.net/bbscon.php?bid=335&id=236629
[7] http://www.newsmth.net/bbscon.php?bid=335&id=209239
[8] http://www.newsmth.net/bbscon.php?bid=335&id=186723
轉載請註明來自parallellabs.c
