無鎖雜湊表的實現

2021-07-13 05:46:58 字數 4534 閱讀 5184

無鎖雜湊表(lock-free hash table )可以提高多執行緒下的效能表現,但是因為實現乙個無鎖雜湊表本身的複雜度不小。(ps:真正的複雜在於出錯之後的除錯,因為多執行緒下的除錯本身就很複雜,引入無鎖資料結構之後,傳統的看堆疊資訊和列印log都基本上沒有意義了。堆疊中的資料可能被併發訪問破壞,而列印log本身可能會改變程式執行時對資料訪問的時序。乙個比較可行的做法是實現乙個無鎖版本和乙個傳統資料結構+鎖的版本,出錯後通過替換來定位是無鎖資料結構本身的bug還是其他邏輯的bug)。所以對乙個專案而言,無鎖資料結構基本上是一把雙刃劍。

很幸運,6年時間足夠我理解dr. cliff click所做的研究。事實上,你不必做一些前沿的探索,去實現乙個完美的無鎖雜湊表。在這裡我將分享我實現的這個版本。我相信有使用c++進行多執行緒開發經驗的程式設計師,可以通過這篇部落格梳理以前的經驗,並且完全理解它。

作為乙個程式設計師,平時我們實現乙個資料結構會本能的盡可能通用。這不是一件壞事,但是當我們把通用當作乙個更重要的目標時,它可能會阻礙我們。在這裡我走向另乙個極端,實現了乙個盡可能簡單的,僅用於一些特殊環境的雜湊表,下面是它的設計約束:

table 只接受型別為32位整數的key和value

所有key必須非零

所有的value必須非零

table的最大數目固定且必須是2的冪

唯一可用的操作是setitem和getitem

有沒有刪除操作

當然你掌握了這種演算法實現機制之後,可以在此基礎上進行擴充套件,而不受這些限制的約束。(rehash,刪除和遍歷,這些都會增加複雜度,而且有引發新的aba問題的可能性)。

有很多種方法來實現乙個雜湊表。這裡我選擇了用我以前的帖子中描述的arrayofitems類做乙個簡單的修改,(前置擴充套件閱讀)a lock-free… linear search?

這個雜湊表被我稱為hashtable1,和arrayofitems一樣,它採用了乙個巨大的key-value pairs陣列實現。

c++

1

2

3

4

5

6

struct

entry

; entry

*m_entries

;

在hashtable1中,僅僅只有陣列本身而沒有使用鏈結來處理碰撞。陣列全部初始化為0,key為0時對應的節點為空。插入時,會通過線性搜尋找到乙個空節點。

arrayofitems和hashtable1之間唯一的區別是,arrayofitems是從0開始做線性搜尋,而hashtable1使用murmurhash3′s integer finalizer演算法得到乙個hash值,然後以這個hash值為起點開始搜尋()

c++

1

2

3

4

5

6

7

8

9

inline

static

uint32_t

integerhash

(uint32

_t h)

當我們使用相同的key做引數呼叫setitem或getitem方法時,它會在相同的index開始做線性搜尋,而使用不同的key時,會在不同的index開始搜尋。通過這種方式,可以提高查詢到對應key所在節點的速度,並且保證多執行緒併發呼叫setitem或getitem的安全性。

setitem的實現。它會掃瞄整個陣列並且將value儲存在與key對應的節點或空節點。這段**與arrayofitems:: setitem幾乎相同,唯一的區別是計算了hash值並且按位與,保證index在陣列邊界內。

c++

1

2

3

4

5

6

7

8

9

10

11

12

13

14

void

hashtable1

::setitem

(uint32_t

key,

uint32_t

value

)

} }

getitem的實現也同樣和arrayofitems::getitem有類似的改變。

c++

1

2

3

4

5

6

7

8

9

10

11

12

13

uint32_t

hashtable1

::getitem

(uint32_t

key)

}最後,就像在以前的帖子中,我們可以優化setitem,第一次判斷是否可以避免使用cas操作。如下這種優化,可以使示例應用程式執行快大約20%。

c++

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

void

hashtable1

::setitem

(uint32_t

key,

uint32_t

value

)

// store the value in this array entry.

mint_store_32_relaxed

(&m_entries

[idx].

value

,value);

return

;

} }

乙個忠告:與arrayofitems一樣,hashtable1上的所有操作都採用了relaxed memory ordering做限制。因此,當在hashtable1中設定標記,共享一些資料供其他執行緒訪問時,必須事先插入release fence。同樣訪問資料的執行緒在呼叫getitem前需要acquire fence。

c++

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

// shared variables

char

message

[256];

hashtable1

collection;

void

publishmessage()

**放在github上,你可以自己編譯和執行。編譯說明見readme.md

在hashtable1沒有滿時—少於80%時—hashtable1表現的很好,我也許應該為這個說法做一些基準測試。但是以以往的常規的雜湊表作為基準,我敢肯定你很難實現出效能更好的無鎖雜湊表。這似乎奇怪,hashtable1基於arrayofitems,看起來會很低效。當然,任何雜湊表中,總會有發生碰撞的風險,而降階到arrayofitems的風險並不為0。但是使用乙個足夠大的陣列和類似murmurhash3這樣的hash函式,這種情況出現的很少。

在實際的工作中,我已經使用了乙個和這個類似的hash-table。這是乙個遊戲開發的專案,我的工作是解決使用記憶體分配跟蹤工具(memory tracker)之後對乙個讀寫鎖激烈的爭用。遷移到無鎖雜湊表的過程非常棘手。相對hashtable1需要更複雜的資料結構,key和value都是指標而不是簡單的整數。因此有必要在雜湊表內部插入memory ordering。最終在此模式下執行:最壞情況下遊戲的幀率提高了4-10 fps。

無鎖有序鍊錶的實現

感謝同事 kevinlynx 在本站發表此文 無鎖有序鍊錶可以保證元素的唯一性,使其可用於雜湊表的桶,甚至直接作為乙個效率不那麼高的map。普通鍊錶的無鎖實現相對簡單點,因為插入元素可以在表頭插,而有序鍊錶的插入則是任意位置。本文主要基於 high performance dynamic lock ...

世界上最簡單的無鎖雜湊表

無鎖雜湊表 lock free hash table 可以提高多執行緒下的效能表現,但是因為實現乙個無鎖雜湊表本身的複雜度不小。ps 真正的複雜在於出錯之後的除錯,因為多執行緒下的除錯本身就很複雜,引入無鎖資料結構之後,傳統的看堆疊資訊和列印log都基本上沒有意義了。堆疊中的資料可能被併發訪問破壞,...

世界上最簡單的無鎖雜湊表

無鎖雜湊表 lock free hash table 可以提高多執行緒下的效能表現,但是因為實現乙個無鎖雜湊表本身的複雜度不小。ps 真正的複雜在於出錯之後的除錯,因為多執行緒下的除錯本身就很複雜,引入無鎖資料結構之後,傳統的看堆疊資訊和列印log都基本上沒有意義了。堆疊中的資料可能被併發訪問破壞,...