成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

關于多線程同步的一切:lock-free/wait-free

開發(fā)
lock-free沒有鎖同步的問題,所有線程無阻礙的執(zhí)行原子指令,而不是等待。

鎖是操作系統(tǒng)提供的一種同步原語,通過在訪問共享資源前加鎖,結束訪問共享資源后解鎖,讓任何時刻只有一個線程訪問共享,本質是做串行化。

程序對共享資源的訪問任務,一般包括三步驟,讀原值,修改值,將新值寫回,用鎖同步的話,就是在確保這三個步驟,不會被打斷,訪問共享資源的臨近代碼區(qū)只有一個線程在同時運行,第一個獲得鎖的線程能往前推進,其他線程只能等著直到持有鎖的線程釋放鎖。

線程同步分為阻塞型同步和非阻塞型同步。

互斥量、信號、條件變量這些系統(tǒng)提供的機制都屬于阻塞型同步,在爭用資源的時候,會導致調用線程阻塞。

而非阻塞型同步是在無鎖的情況下,通過某種算法和技術手段實現(xiàn)不用阻塞而同步。

鎖是阻塞(Blocking)同步機制,阻塞同步機制的缺陷是可能掛起你的程序,如果持有鎖的線程crash,則鎖永遠得不到釋放,而其他線程則將陷入無限等待,另外,它也可能導致優(yōu)先級倒轉等問題。

所以,我們需要非阻塞(Non-Blocking)的同步機制。

什么是lock-free?

lock-free沒有鎖同步的問題,所有線程無阻礙的執(zhí)行原子指令,而不是等待。

比如一個線程讀atomic類型變量,一個線程寫atomic變量,它們沒有任何等待,硬件原子指令確保不會出現(xiàn)數(shù)據(jù)不一致,寫入數(shù)據(jù)不會出現(xiàn)半完成,讀取數(shù)據(jù)也不會讀一半。

圖片

那到底什么是lock-free?

有人說lock-free就是不使用mutex / semaphores之類的無鎖(lock-Less)編程,這句話嚴格來說并不對。

我們先看一下wiki對Lock-free的描述:

> Lock-freedom allows individual threads to starve but guarantees system-wide throughput. An algorithm is lock-free if, when the program threads are run for a sufficiently long time, at least one of the threads makes progress (for some sensible definition of progress). All wait-free algorithms are lock-free.

> In particular, if one thread is suspended, then a lock-free algorithm guarantees that the remaining threads can still make progress. Hence, if two threads can contend for the same mutex lock or spinlock, then the algorithm is not lock-free. (If we suspend one thread that holds the lock, then the second thread will block.)

  • 第一段:lock-free允許單個線程饑餓但保證系統(tǒng)級吞吐。如果一個程序的線程執(zhí)行足夠長的時間,那么至少一個線程會往前推進,那么這個算法就是lock-free的。
  • 第二段:尤其是,如果一個線程被暫停,lock-free算法保證其他線程依然能夠往前推進。

第一段是給lock free下定義,第二段是解釋。

因此,如果2個線程競爭同一個互斥鎖或者自旋鎖,那它就不是lock-free的。

因為如果我們暫停持有鎖的線程,那么另一個線程會被阻塞。

wiki的這段描述很抽象,它不夠直觀,稍微再解釋一下:

lock-free描述的是代碼邏輯的屬性,不使用鎖的代碼,大部分具有這種屬性。所以,我們經(jīng)常會混淆這lock-free和無鎖這2個概念。

其實,lock-free是對代碼(算法)性質的描述,是屬性,而無鎖是說代碼如何實現(xiàn),是手段。

lock-free的關鍵描述是:如果一個線程被暫停,那么其他線程應能繼續(xù)前進,它需要有系統(tǒng)級(system-wide)的吞吐。

我們從反面舉例來看,假設我們要借助鎖實現(xiàn)一個無鎖隊列,我們可以直接使用線程不安全的std::queue + std::mutex來做:

template <typename T>
class Queue {
public:
void push(const T& t) {
q_mutex.lock();
q.push(t);
q_mutex.unlock();
}
private:
std::queue<T> q;
std::mutex q_mutex;
};

如果有線程A/B/C同時執(zhí)行push方法,最先進入的線程A獲得互斥鎖。

線程B和C因為獲取不到互斥鎖而陷入等待。

這個時候,線程A如果因為某個原因(如出現(xiàn)異常,或者等待某個資源)而被永久掛起,那么同樣執(zhí)行push的線程B/C將被永久掛起,系統(tǒng)整體(system-wide)沒法推進。這顯然不符合lock-free的要求。

因此:所有基于鎖(包括spinlock)的并發(fā)實現(xiàn),都不是lock-free的。

因為它們都會遇到同樣的問題:即如果永久暫停當前占有鎖的線程/進程的執(zhí)行,將會阻塞其他線程/進程的執(zhí)行。

而對照lock-free的描述,它允許部分process(理解為執(zhí)行流)餓死但必須保證整體邏輯的持續(xù)前進,基于鎖的并發(fā)顯然是違背lock-free要求的。

CAS loop實現(xiàn)lock-free

Lock-Free同步主要依靠CPU提供的read-modify-write原語,著名的“比較和交換”CAS(Compare And Swap)在X86機器上是通過cmpxchg系列指令實現(xiàn)的原子操作,CAS邏輯上用代碼表達是這樣的:

bool CAS(T* ptr, T expect_value, T new_value) {
if (*ptr != expect_value) {
return false;
}
*ptr = new_value;
return true;
}

CAS接受3個參數(shù):

  • 內存地址
  • 期望值,這個值通常傳第一個參數(shù)所指內存地址中的舊值
  • 新值

邏輯描述:CAS比較內存地址中的值和期望值,如果不相同就返回失敗,如果相同就將新值寫入內存并返回成功。

當然這個C函數(shù)描述的只是CAS的邏輯,這個函數(shù)操作不是原子的,因為它可以劃分成幾個步驟:讀取內存值、判斷、寫入新值,各步驟之間是可以插入其他操作的。

不過前面講了,原子指令相當于把這些步驟打包,它可能是通過`lock; cmpxchg`實現(xiàn)的,但那是實現(xiàn)細節(jié),程序員更應該注重在邏輯上理解它的行為。

通過CAS實現(xiàn)Lock-free的代碼通常借助循環(huán),代碼如下:

do {
T expect_value = *ptr;
} while (!CAS(ptr, expect_value, new_value));

  • 創(chuàng)建共享數(shù)據(jù)的本地副本,expect_value
  • 根據(jù)需要修改本地副本,從ptr指向的共享數(shù)據(jù)里load后賦值給expect_value
  • 檢查共享的數(shù)據(jù)跟本地副本是否相等,如果相等,則把新值復制到共享數(shù)據(jù)

第三步是關鍵,雖然CAS是原子的,但加載expect_value跟CAS這2個步驟,并不是原子的。

所以,我們需要借助循環(huán),如果ptr內存位置的值沒有變(*ptr == expect_value),那就存入新值返回成功;否則說明加載expect_value后,ptr指向的內存位置被其他線程修改了,這時候就返回失敗,重新加載expect_value,重試,直到成功為止。

CAS loop支持多線程并發(fā)寫,這個特點太有用了,因為多線程同步,很多時候都面臨多寫的問題,我們可以基于cas實現(xiàn)Fetch-and-add(FAA)算法,它看起來像這樣:

T faa(T& t) {
T temp = t;
while (!compare_and_swap(x, temp, temp + 1));
}

第一步加載共享數(shù)據(jù)的值到temp,第二步比較+存入新值,直到成功。

lock-free棧

下面是C++ atomic compare_exchange_weak()實現(xiàn)的一個lock-free堆棧(來自CppReference):

template <typename T>
struct node {
T data;
node* next;
node(const T& data) : data(data), next(nullptr) {}
};

template <typename T>
class stack {
std::atomic<node<T>*> head;
public:
void push(const T& data) {
node<T>* new_node = new node<T>(data);
new_node->next = head.load(std::memory_order_relaxed);
while (!head.compare_exchange_weak(new_node->next, new_node,
std::memory_order_release,
std::memory_order_relaxed));
}
};

代碼解析:

  • 節(jié)點(node)保存T類型的數(shù)據(jù)data,并且持有指向下一個節(jié)點的指針
  • `std::atomic<node<T>*>`類型表明atomic里放置的是Node的指針,而非Node本身,因為指針在64位系統(tǒng)上是8字節(jié),等于機器字長,再長沒法保證原子性
  • stack類包含head成員,head是一個指向頭結點的指針,頭結點指針相當于堆頂指針,剛開始沒有節(jié)點,head為NULL
  • push函數(shù)里,先根據(jù)data值創(chuàng)建新節(jié)點,然后要把它放到堆頂
  • 因為是用鏈表實現(xiàn)的棧,所以,如果新節(jié)點要成為新的堆頂(相當于新節(jié)點作為新的頭結點插入),那么新節(jié)點的next域要指向原來的頭結點,并讓head指向新節(jié)點
  • `new_node->next = head.load`把新節(jié)點的next域指向原頭結點,然后`head.compare_exchange_weak(new_node->next, new_node)`,讓head指向新節(jié)點
  • C++ atomic的compare_exchange_weak()跟上述的CAS稍有不同,head.load()不等于new_node->next的時候,它會把head.load()的值重新加載到new_node->next
  • 所以,在加載head值和cas之間,如果其他線程調用push操作,改變了head的值,那沒有關系,該線程的本次cas失敗,下次重試便可以了
  • 多個線程同時push時,任一線程在任意步驟阻塞/掛起,其他線程都會繼續(xù)執(zhí)行并最終返回,無非就是多執(zhí)行幾次while循環(huán)

這樣的行為邏輯顯然符合lock-free的定義,注意用cas+loop實現(xiàn)自旋鎖不符合lock-free的定義,注意區(qū)分。

ABA問題

CAS經(jīng)常伴隨ABA問題,考慮前面的CAS邏輯,CAS里會做判等,判等的2個操作數(shù),一個是前步加載的內存地址的值,另一個是再次從內存地址讀取的值,如果2個操作數(shù)相等,它便認為內存位置的值沒變。

但實際上,如果“兩次讀取一個內存位置的值相同,則說明該內存位置沒變”,這個假設不一定成立,為什么呢?

假設線程1在前面一步從內存位置加載數(shù)據(jù)后。

線程2切入,將該內存位置的數(shù)據(jù)從A修改為B,然后又修改為A。

等到線程1繼續(xù)執(zhí)行CAS的時候,它觀測到的內存位置值未變(依然是A),因為線程2將數(shù)據(jù)從A修改到B,再修改成A。

線程1兩次讀到了相同的值,它便斷定內存位置沒有被修改,實際并非如此,線程2改了內存位置。

基于上述邏輯行事,就有可能出現(xiàn)未定義的結果。

這就是經(jīng)典的ABA問題,會不會出問題,完全取決于你的程序邏輯,有些邏輯可以容忍ABA問題,而有些不可以。

ABA問題很多時候由內存復用引起,比如一塊內存被回收后又被分配,地址值不變,但這個對象已經(jīng)不是之前的那個對象了,有很多解決ABA問題的技術手段,比如增加版本號等等,目的無非是去識別這種變化。

何為wait-free?

wiki關于wait-free的詞條解釋:

> Wait-freedom is the strongest non-blocking guarantee of progress, combining guaranteed system-wide throughput with starvation-freedom

> An algorithm is wait-free if every operation has a bound on the number of steps the algorithm will take before the operation completes.[15] This property is critical for real-time systems and is always nice to have as long as the performance cost is not too high

翻譯過來就是:wait-free有著最強的非阻塞進度保證,wait-free有系統(tǒng)級吞吐兼具無饑餓特征。

如果一個算法的每個操作完成都只有有限操作步數(shù),那么這個算法就是wait-free的。

這個特征對于實時系統(tǒng)非常關鍵,且它的性能成本不會太高。

圖片

wait-free比lock-free更嚴格,所有wait-free算法都是lock-free的,反之不成立,wait-free是lock-free的子集。

wait-free的關鍵特征是所有步驟都在有限步驟完成,所以前面的`cas + loop`實現(xiàn)的lock-free棧就不是wait-free的。

因為理論上,如果調用push的線程是個倒霉蛋,一直有其他線程push且恰好又都成功了,則這個倒霉蛋線程的cas會一直失敗,一直循環(huán)下去,這與wait-free每個操作都必須在有限步驟完成的要求相沖突。wait-free的嘗試次數(shù)通常跟線程數(shù)有關,線程數(shù)越多,則這個有限的上限就越大。

但前面講的atomic fetch_add則是wait-free的,因為它不會失敗。

簡單點說,lock-free可以有循環(huán),而wait-free連循環(huán)都不應該有。

wait-free非常難做,以前一直看不到wait-free的數(shù)據(jù)結構和算法實現(xiàn),直到2011才有人搞出了一個wait-free隊列,雖然這個隊列也用到了cas,但是它為每一步發(fā)送的操作提供了一個state array,為每個操作賦予一個number,從而保證有限步完成入隊出隊操作,論文鏈接:

(wait-free queue):[http://www.cs.technion.ac.il/~erez/Papers/wfquque-ppopp.pdf]

何為Obstruction-free?

Obstruction-free提供比lock-free更弱的一個非阻塞進度保證,所有l(wèi)ock-free都屬于Obstruction-free。

Obstruction-free翻譯過來叫無障礙,是指在任何時間點,一個孤立運行線程的每一個操作可以在有限步之內結束。只要沒有競爭,線程就可以持續(xù)運行,一旦共享數(shù)據(jù)被修改,Obstruction-free要求中止已經(jīng)完成的部分操作,并進行回滾,obstruction-free是并發(fā)級別更低的非阻塞并發(fā),該算法在不出現(xiàn)沖突性操作的情況下提供單線程式的執(zhí)行進度保證。

obstruction-freedom要求可以中止任何部分完成的操作并且能夠回滾已做的更改,為了內容完備性,把obstruction-free列在這里。

無鎖數(shù)據(jù)結構

一些無鎖(阻塞)數(shù)據(jù)結構不需要特殊原子操作原語即可實現(xiàn),例如:

  • 支持單線程讀和單線程寫的Ring Buffer先進先出隊列,通過把容量設置為2^n,利用整型回繞特點+內存屏障就可以實現(xiàn),參考linux內核的kfifo
  • 帶單寫線程和任意數(shù)讀線程的讀拷貝更新(RCU),通常,讀無等待(wait-free),寫無鎖(lock-free)
  • 帶多寫線程和任意數(shù)讀線程的讀拷貝更新(RCU),通常,讀無等待(wait-free),寫用鎖做串行化

無鎖數(shù)據(jù)結構實現(xiàn)起來比較困難,非必要不要自己去實現(xiàn)。

自旋鎖

在cpu核上自旋,粘著cpu不停的測試,直到其他cpu解鎖,這是一種消耗cpu的加鎖方式,適合持有鎖的時間非常短的情況,它基于一種假設:睡眠導致的調度開銷大于在cpu上自旋測試的開銷。

  • 自旋鎖也叫優(yōu)雅粒度的鎖,跟操作系統(tǒng)提供的阻塞機制的粗粒度鎖(mutex和信號量)對應。
  • 自旋鎖一般不應該被長時間持有,如果持有鎖的時間可能比較長,那就用操作系統(tǒng)為你提供的粗粒度的鎖就好了。
  • 線程持有自旋鎖的時候,線程一般不應該被調度走,內核層可以禁中斷禁調度保障這一點,但應用層程序一般無法避免線程被調度走,所以應用層使用自旋鎖其實得不到保障。
  • 自旋鎖不可遞歸。
  • 自旋鎖常用來追求低延時,而不是為了提升系統(tǒng)吞吐,因為自旋鎖,不會把執(zhí)行線程調度走,不會阻塞(睡眠)。
責任編輯:趙寧寧 來源: 碼磚雜役
相關推薦

2022-08-17 06:25:19

偽共享多線程

2022-08-21 17:35:31

原子多線程

2022-08-13 11:53:52

多線程內存

2020-09-11 10:55:10

useState組件前端

2018-11-23 11:17:24

負載均衡分布式系統(tǒng)架構

2021-02-19 23:08:27

軟件測試軟件開發(fā)

2021-02-28 09:47:54

軟件架構軟件開發(fā)軟件設計

2020-10-14 08:04:28

JavaScrip

2021-05-28 07:12:59

Python閉包函數(shù)

2023-04-20 10:15:57

React組件Render

2011-11-30 09:28:37

iCloud信息圖云計算

2022-04-02 09:38:00

CSS3flex布局方式

2023-02-10 08:44:05

KafkaLinkedIn模式

2018-01-05 14:23:36

計算機負載均衡存儲

2023-07-10 10:36:17

人工智能AI

2021-08-09 14:40:02

物聯(lián)網(wǎng)IOT智能家居

2023-04-12 14:04:48

光纖網(wǎng)絡

2018-01-17 09:15:52

負載均衡算法

2012-12-31 11:22:58

開源開放

2023-10-12 07:06:32

點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 国产精品电影在线观看 | 涩涩视频网站在线观看 | 亚洲精品在线播放 | 国产一区二区三区视频在线观看 | 国产免费一区二区 | 国产高清在线 | 久久com | 91高清免费 | 国产激情99 | 国产精品成人一区二区三区 | 成av人电影在线 | 国产综合久久 | 日韩一区二区在线免费观看 | 狠狠av| 中文字幕一区二区三区精彩视频 | 一区二区在线免费播放 | 欧美性大战久久久久久久蜜臀 | 成人精品鲁一区一区二区 | 日韩在线一区二区 | 国内精品久久久久久 | 91电影院| 久久久噜噜噜久久中文字幕色伊伊 | 亚洲精品68久久久一区 | 天堂一区二区三区 | 日日干干 | 丁香六月伊人 | 精品国产乱码久久久久久蜜臀 | 亚洲在线免费观看 | 91亚洲国产| 成人国内精品久久久久一区 | 久久亚洲春色中文字幕久久久 | 欧美国产日韩一区二区三区 | 国产日韩欧美 | 久久久久久九九九九九九 | 国产乱码精品一区二区三区忘忧草 | 91精品久久久久久久久久入口 | 国产一区视频在线 | 久久久精品一区 | 91国内视频在线 | 呦呦在线视频 | 日韩一二三区视频 |