Recommended
More Related Content
What's hot
What's hot (20)
Similar to 冬のLock free祭り safe
Similar to 冬のLock free祭り safe (20)
More from Kumazaki Hiroki
More from Kumazaki Hiroki (18)
Recently uploaded
Recently uploaded (9)
冬のLock free祭り safe
- 7. ポラックの法則 半分の性能のコアなら1/4の面積 ¼の面積なら同じ面積に４個積める！ ½の性能 × 4コア = 2倍の性能！！ 1/2 1/2 1/2 1/2
- 10. なんで普及しないの？
- 11. We are the Bottleneck! 情報工学の発展が追い付いていない！ ヽ('ω')ﾉ三ヽ('ω')ﾉもうしわけねぇもうしわけ ねぇ
- 13. そして タダ飯の時代よ今再び！
- 15. What is Blocking? ビーチフラッグを例に CPU
- 16. What is Blocking? 排他すると ロッ ク OK! クリティカルセク ション
- 17. What is Blocking? クリティカルセクションは危険がいっぱ い クリティカルセク ション
- 18. What is Blocking? クリティカルセクションは危険がいっぱ い クリティカルセク ション
- 19. What is Blocking? コアが増えるほどに問題が顕著に！ 早くしろよ… 早くしろよ… 早くしろよ… 早くしろよ… 早くしろよ… 早くしろよ… 早くしろよ… 早くしろよ… 早くしろよ… クリティカルセク ション
- 20. そこで Lock-free クリティカルセクションを 作らないので 他のスレッドを足止めしない！
- 21. Lockを用いないとどうなるか CPU内部では処理は複数のステップで行われ る 1.xを読み出す ++x; 2.読んだ値に +1 3.xを保存する
- 22. Lockを用いないとどうなるか 複数スレッドが同時に行うと x==1 スレッド スレッド A B 1.xを読み出す(1) 1.xを読み出す(2) 2.読んだ値に +1 2.読んだ値に +1 3.xを保存する(1) 3.xを保存する(3) OK! x==3
- 23. Lockを用いないとどうなるか 複数スレッドが同時に行うと破綻する場合が x==1 ある スレッド スレッド A B 1.xを読み出す(1) 1.xを読み出す(1) 2.読んだ値に +1 2.読んだ値に +1 3.xを保存する(2) 3.xを保存する(2) 数が合わない x==2
- 24. 道具の紹介 「targetが期待通りの値だったら置換」を一 気に行う命令 以後ではCASと略します bool compare_and_swap(int* target, int expected, int newval){ if(*target == expected){ *target = newval; return true; } return false; }
- 25. CASを使ってみよう Lock-free共有カウンタの例 int x; void add1(){ int old,new; do{ old = x; new = old+1; 失敗してたらやり直す }while(!cas(&x, old, new)); }
- 26. CASを使ってみよう CASのお陰で衝突しても破綻しない x==1 スレッド スレッド A B 1. xを読み出す(1) 1. xを読み出す(1) 2. 読んだ値に +1 3. 値が1なら2へCAS 2. 読んだ値に +1 4. 失敗したので再挑戦 5. xを読み出す(2) 3. 値が1なら2へCAS 6. 読んだ値に +1 7. 値が2なら3へCAS 数が合う！ x==3
- 27. 冬のLock-free祭り マルチスレッドReadyでありながらロックを用 いないデータ構造 話す予定のおしながき Lock-free Stack Lock-free Queue Lock-free List Lock-free Hashmap Lock-free SkipList Lock-free Btree Dynamic STM(Obstruction-free STM) ？？？
- 28. Lock-free Stack Compare And Swapの正しい使い方
- 29. Lock-free Stack ↓ポインタ A Head CAS 「Headが指している物を指したノードを作って CAS」
- 30. Lock-free Stack CAS CAS CAS Head A B C D 失敗した！
- 31. Lock-free Stack A CAS Head CAS B C D また失敗した！
- 32. Lock-free Stack A Head CAS C B D
- 33. Lock-free Stackからpop A Head CAS C D B
- 35. Lock-free QUEUE 不変条件に手を加える
- 36. Lock-free Queue の Deque Tail Head
- 37. Lock-free Queue の Deque Deque操作は簡単 Lock-free Stackと同じ挙動なので
- 38. Lock-free Queue の Deque Tail Head CAS CAS
- 39. Lock-free Queue の Enque Enque操作 1. Enqueしたい要素eを用意する 2. 末尾のノードが指すポインタがeを指すようCAS 3. Tailポインタがeを指すようCAS 2ステップ必 要
- 40. Lock-free Queue の Enque Tail Head CAS CAS
- 41. Lock-free Queue の Enque Tail Head CAS 構造が破綻 CAS CAS CPU1 CPU2 1. 要素eを用意する 1. 要素eを用意する 2. 末尾をCAS 2. 末尾をCAS 3. TailポインタをCAS 3. TailポインタをCAS
- 42. 不変条件を考える アルゴリズムは必ず何かしらの前提が必要 マルチスレッドプログラムでもそれは同じ 常にその条件を満たし続けるのは無理→ロッ ク 条件守ってる！ 条件守ってる！ 時間軸→ 条件守ってない！
- 43. 不変条件を守る 他のCPUが思いもよらない変更を加えてくる 危険な瞬間 CPU1 CPU2 CPU3 CPU4 時間軸→
- 46. ロックの目的と効果 普通にプログラムを書くとどうしても不変条 件を破壊する瞬間が生まれてしまう そこはロックで守るのが普通 void queue::enque(const T& v){ ↓時間軸 node* const new_node = new node(v); node* const tail = que_tail_; tail->next = new_node; que_tail = new_node; } 危ない
- 47. ロックの目的と効果 Lock-free Stackは不変条件を満たさない瞬間 を外部から観測されないように最小化して CASで片づけられた CPU1 CAS CAS CPU2 CAS CAS CPU3 CAS CPU4 CAS CAS
- 48. ロックの目的と効果 Lock-free Queueは2度CASが要るのでタイミ ングによって危険 危険な瞬間 CPU1 CAS CAS CAS CAS CPU2 CAS CAS CAS CAS CPU3 CAS CAS CPU4 CAS CAS CAS CAS
- 49. Lock-free Queueはどうするのか 不変条件 Headがキューの先頭を指す Tailがキューの末尾を指す Tail以外のノードは必ず有効なノードを指す 条件を緩め 不変条件 る Headがキューの先頭を指す Tailがキューの末尾を指さないかもしれない Tail以外のノードは必ず有効なノードを指す
- 50. Tailが末尾を指さないとは？ 末尾を指してる Tail Head 末尾を指してない Tail Head
- 51. 解決 「Tailが遅れてたらみんな手伝ってあげてね」 「Tailの更新に失敗してもみんな気にしないで ね」 Tail Head CAS 破綻しない！ CAS CPU1 CPU2 1. 要素eを用意する 1. 要素eを用意する 2. Tailが遅れてたら進める 2. Tailが遅れてたら進める 3. 末尾をCAS 3. 末尾をCAS 4. TailポインタをCAS(失 4. TailポインタをCAS 敗)
- 52. Lock-free Queueかっこいい！ EnqueとDequeの共同作業！ T deque(){ while(1){ const Node* const first = mHead; void enque(const T& v){ const Node* const last = mTail; const Node* const node = new Node(v); const Node* const next = first->mNext; while(1){ if(first != mHead){ continue;} const Node* const last = mTail; if(first == last){ const Node* const next = last->mNext; if(next == NULL){ if(last != mTail){ continue; } while(mHead->mNext == if(next == NULL){ NULL){ usleep(1); } if(compare_and_set(&last- continue; >mNext, next, node)){ } compare_and_set(&mTail, last, node); compare_and_set(&mTail,last,next); return; }else{ } T result = next->mValue; }else{ if(compare_and_set(&mHead, first, next)){ compare_and_set(&mTail, last, next); delete first; } return result; } } } } }
- 53. Lock-free Queueかっこいい！ EnqueとDequeの共同作業！ T deque(){ while(1){ const Node* const first = mHead; void enque(const T& v){ const Node* const last = mTail; const Node* const node = new Node(v); const Node* const next = first->mNext; while(1){ if(first != mHead){ continue;} const Node* const last = mTail; if(first == last){ const Node* const next = last->mNext; if(next == NULL){ if(last != mTail){ continue; } while(mHead->mNext == if(next == NULL){ NULL){ usleep(1); } if(compare_and_set(&last->mNext, next, continue; node)){ } compare_and_set(&mTail, last, node); compare_and_set(&mTail,last,next); return; }else{ } T result = next->mValue; }else{ if(compare_and_set(&mHead, first, next)){ compare_and_set(&mTail, last, next); delete first; } return result; } } } } }
- 55. MessagePassing 「メッセージを渡す」という哲学に基づいて、 操作の実行順序をメッセージ順にしてしまう こと ですよね？ Deq Enq Deq Deq Enq Queue
- 56. Lock-free 例えるならこんな感じ！ Deq Enq Deq Queue Deq Enq
- 57. どういうこと？ スケールする！ FASTER Single-lock Lock-free
- 63. 悲観的ロック ノードごとにロックを用意 ロック・アンロックしながら「歩く」 Head • かなり遅くなる • 他のスレッドのイテレーションを追い越せない
- 64. 楽観的ロック 必要になるまでロックを取らない Head これでいいんじゃない？
- 65. 楽観的ロック だめなんです ロックを2つ取っ 私の安定性…低すぎ… おりゃ！ て これ消すぞー！ Head Segmentation Fault これ消すぞー 消したぞー
- 68. さぁLock-freeだ
- 69. 挿入処理 • リストの繋ぎ替え処理にCASを使用して衝突を回避 し、検索の邪魔をしない • 道路封鎖せず道路工事してる感じ CAS
- 70. 挿入処理 CASを使う事によって、同一の場所に同時に 複数の挿入が発生しても 大丈夫！ CAS CAS CAS 失敗した！
- 71. 削除処理 挿入処理と同様に、ポインタをCASで繋ぎ変 える CAS 追い出しに成功したスレッドがdelete
- 72. このアルゴリズムにはミスがある
- 73. 問題が 連続したノードを同時に削除しようとすると データ構造が破壊される CAS CAS Segmentation Fault
- 74. 問題が 削除と挿入がぶつかっても破壊される CAS CAS Memory Leak
- 75. 解決策 ノードの削除を「マーキング」「ポインタ繋 ぎかえ」の2段階に分ける マーキングされてたら誰でも削除を手伝う ポインタ繋ぎかえに失敗しても気にしない マーキング前と後の2状態に対して操作を記 述
- 76. マーキングはどこに？ ポインタの1bit目をマーキング対象に 動的確保したメモリは4の倍数ぐらいにはAlignされてる つまり1bit目は通常0 マーキング処理もCASを用いる ココ！ 順序づけ大事 なぜそんなところに埋め込むの？ １回のCASで１word分しか操作できない 何とかして削除マークとポインタをAtomicにした い
- 77. 正しい削除手順 2回CASを使う CAS CAS
- 78. さっきのはどうなるか CAS CAS CAS CAS CAS マーキングにより CAS失敗する
- 79. さっきのはどうなるか CAS CAS マーキングにより CAS CAS失敗する
- 80. 素晴らしい！！
- 83. 細粒度Lock Hashmap 0 1 2 3 4 5 6 7 全部のバケットにロックを取り付けてやる方 法 実はあんまり効率よくない
- 84. Striped Lock Hashmap 0 1 2 3 4 5 6 7 固定数のLockをmoduloでバケットに割り当てる スレッドの数が膨大にならない限りロックそのものが 増えても恩恵がないため バケットごとに対応するロックが縞模様になるので Striped
- 85. java.util.concurrent.ConcurrentHashMap 0 1 2 3 4 5 6 7 volatile final 基本的にStriped Lockだけど、成功する検索は wait-free 失敗する検索はロックを取ってもう一回行う 削除はチェインを部分的にまるっとRCU バケットの拡張は再帰的にロックを全て獲得しながら
- 86. Lock free?
- 87. Lockの無くし方を考える 0 1 2 3 4 5 6 7 線形リスト部分はLock-free Listを使えばいい バケット部分の拡張が鬼門
- 88. どうするバケット拡張 あらかじめ充分巨大なバケットにして しまう 0 富豪的過ぎて実用的でない 1 2 CASでバケット列を複製 0 3 1 4 複製作業中に挿入・削除が走る 2 5 3 6 一貫性無理☆ 4 7 5 6 7 8 9 10 11
- 89. バケットの拡張が 困難
- 91. 全体図 内部を昇順のLock-free List一本で集約 番兵ノード 00000010 00000001 00000011 データノード ↓ ↓ ↓ 01000000 10000000 11000000 00 02 40 48 6d 7f 80 8a c0 74 0 1 Hashmapのインデックス値を逆順にしてリ 2 ストに投入 3
- 92. どういうこと？ 普通はバケットにデータを吊るしてる 0 02 1 48 6d 7f 2 8a 3 74 こっちはデータの間にバケットの目印を吊る す 00 02 1本のList 0 40 48 6d 7f 1 2 80 8a 3 c0 74
- 93. データの挿入 1. 対象となるデータのハッシュ値を算出→2 2. ハッシュ値に対応するテーブルにアクセス 3. テーブルに番兵ノードへのポインタが書いてあるた め対応するノードへジャンプ 4. 番兵ノードの指すポインタをたどっていけばHash値 の昇順にデータが並んでいるため、対応する場所に 挿入 5. リストが昇順に並んでいるという前提は崩れない！ 00 02 40 48 6d 7f 80 8a c0 74 0 1 69 2 3
- 94. テーブルの拡張 番兵ノードの間に挟まるアイテムの数が一定数を超 えた場合にテーブルを拡張する 左のテーブルは工夫してあり、基本的に初期化以降 immutable 詳細な部分は論文で 00 02 40 48 6d 7f 80 8a c0 74 0 1 2 3 4 5 6 7
- 95. テーブルの拡張 1. 拡張操作はテーブルを大きくするだけでおしまい(CASでも可 能) 2. テーブル拡張後は新規探索は新しいテーブル上で行う 3. テーブルが未初期化ならその一個左の番兵ノードから探索 4. 番兵ノードが挿入されているべき個所を見つけ次第、番兵 ノードを挿入する 5. 目的の場所を見つけたら挿入 6. リストが昇順に並んでいるという前提は崩れない 00 02 40 48 60 6d 69 7f 80 8a c0 74 0 1 2 3 4 5 62 6 7
- 96. ロックなしで並行動作する！ 何があっても リストが昇順に並んでいるという前提は 崩れない 挿入と拡張が同時に走っても 削除と挿入が同時に走っても 大丈夫！
- 97. FAST 驚異的なスケーラビリティ
- 98. Lock-free java.util.concurrent.ConcurrentHashMap FAST 性能負けてる！！！ スレッド数
- 101. SkipList ご存じ・・・ですよね？
- 102. SkipList 順序関係のあるデータをO(log n)で検索・挿 入・削除ができるデータ構造 2分木とモロ被り 乱数に依存するため木と違いリバランスする 必要が無い 平衡2分木を平衡に扱うにはリバランス専用のスレッドを 別に立てる方法が現時点で一番高いスループットの出る 方法だったような… LevelDBの中で使われていてちょっと話題に
- 103. SkipList 昇順に並べた普通のリスト に高レベルなリストを加えたもの レベル1上がる毎に1/2のノードが間引かれる -∞ 33 ∞ -∞ 12 33 ∞ -∞ 12 33 64 ∞ -∞ 3 12 33 51 64 ∞ -∞ 3 8 12 16 33 51 64 ∞ -∞ 3 8 12 16 29 33 51 64 ∞
- 104. SkipListでの検索 高いレベルから順に辿っていくだけ 新幹線・特急・快速・鈍行と乗り換えるイメージ 29どこー？ -∞ 33 ∞ -∞ 12 33 ∞ -∞ 12 33 64 ∞ -∞ 3 12 33 51 64 あったー！ ∞ -∞ 3 8 12 16 33 51 64 ∞ -∞ 3 8 12 16 29 33 51 64 ∞
- 107. Lock-based Skip List 1. ここに挿入したいとする 2. そこ以前のリンクの状態を記憶 3. 昇順にロックを獲得 4. 2の時に記憶した内容と現在の内容が一致していることを確認 5. 全部一致したら下から順にリンクを繋ぎ変えていく
- 108. Lock-based Skip List できました！ 実際は線形化ポイントを確定するため FullyLinkedビットを用いて線形化します 詳しくはgithub.com/kumagi/sl
- 109. さあ Lock-freeだ
- 111. Lock-free SkipListへの挿入 1. 最下位リストへの挿入を行う 2. 下のレベルから順に上位リストのリンクを繋ぎ変える 3. 繋ぎ変える途中で他人に書き換えられてたら前後の情報を 再確認して繋ぎ変えを続行
- 112. Lock-free SkipListへの挿入 1. 最下位リストへの挿入を行う 2. 下のレベルから順に上位リストのリンクを繋ぎ変える 3. 繋ぎ変える途中で他人に書き換えられてたら前後の情報を 再確認して繋ぎ変えを続行
- 113. Lock-free SkipListでの削除 1. 対象物の前後の関係を洗い出す 2. 上位ノードから順番に削除マークを振って いく 3. 上位ノードから順に追い出していく
- 115. 挿入・挿入の衝突 やりなおすだけ 割り込んだ 最下位レベルで割り込まれた場合は初めからやり直す 通常のLock-free Listと同様の作法
- 116. 挿入・挿入の衝突 割り込んだ 最下位以外で割りこまれたらそこから再開 最下位以外は厳密に一貫している必要はないので OK
- 117. 挿入・削除の衝突 削除開始 削除はLock-free Listと同じくマーキングによってCASが失 敗する仕組みになっている そしてやり直すだけ
- 120. みんな大好きBtree 18 16 28 5 7 13 16 22 25 33 HashMapと並ぶデータベースの基礎技術 O(log n)のアクセス速度で大量のデータに向 く
- 121. 普通のBtreeの挿入操作 26 18 16 25 28 28 足りない！ 5 7 13 16 22 22 25 26 33 Split ノードに余裕がなくなった時にSplit操作を行う 余裕のないノードしかSplit操作は行われない 削除はノードの中身が半分を割った時にmerge操 作
- 122. Lock-free!
- 123. Lock-free化 Root CAS 複製 複製 複製 ここに挿入したい 必要なデータをすべて複製してしまえばいい
- 124. Lock-free化 Root Split 必要なデータをすべて複製してしまえばいい SplitやMergeも全く同様。部分木を丸ごと作り直す
- 125. Lock-free化 Root 割り込まれたので 割り込んだ別スレッ CAS失敗→初めから ド やりなおし 必要なデータをすべて複製してしまえばいい SplitやMergeも全く同様。部分木を丸ごと作り直す 衝突したらそのスレッドは初めからやり直し すべての操作はRootに対するCASで直列化
- 128. Dynamic Software Transactional Memory 何千箇所でもCASだけで同時に！
- 131. あなたが本当に欲しかった物 トイレのカギを考えましょう この姿じゃ男子トイレ から出れない…！
- 132. あなたが本当に欲しかった物 今をときめく男の娘に必要なのは 「堅牢なだけのトイレの鍵ではない …！」 いくらデータ構造が強固でスケーラブルに なっても実地で使えなければ意味がない…！ 「Composabilityがない」とも言う コードを使いまわせないのはソフトウェア工学の 世の中のすべてのロックを 敗北 生まれる前に消し去りたい 過去と未来のすべてのロックをこの手で
- 133. そこでSoftwareTransactionalMemory 複数の操作をSerializableな分離レベルで実行 1ワードのCASのみを使う 単一ロックよりもスケールする タダ飯の時代の再来！？
- 135. SoftwareTransactionalMemory 内部ではこのように扱う A Old New Owner Commit B Old New Owner Abort
- 136. SoftwareTransactionalMemory どういう意味か A Old New Owner Commit スレッド スレッドの のステー ステータス タス B Old New Owner Abort
- 137. SoftwareTransactionalMemory ステータスは Commit （既に作業を終えた） Abort （一時的に作業を止めた） Active （現在作業中である） Commit のどれかの状態をとる スレッド スレッドの のステー Commit状態ならNew ステータス タス Abort状態ならOld )を読みだす! Abort Active状態なら競合解決（後述）へ
- 138. SoftwareTransactionalMemory つまり これらが最新の値 A Old New Owner Commit B Old New Owner Abort
- 139. SoftwareTransactionalMemory A,Bの２つを一気に更新する事例 A Commit B Abort
- 140. SoftwareTransactionalMemory 自分のステータスを保存 Active A Commit B Abort
- 141. SoftwareTransactionalMemory Active CAS A Commit CAS B Abort
- 142. SoftwareTransactionalMemory CAS Commit Active A 最新の値 B
- 143. 邪魔が入る場合 Active A B欲しい… Active B
- 144. 邪魔が入る場合 Active Abort A CAS 最新の値 Active B Bを獲得！
- 145. どう凄いのか A 複数個所の最新情報 B がCAS1回で変わる C Commit Active Abort D E
- 148. Transaction on Key Value Store 僕の修士論文(予定)
- 150. キーバリューストアでのCAS すべてのキーバリューペアがバリュー値と 共にuniq値を持っていて、書き換え時に更 新される 1. Getsコマンドでuniq値を獲得 2. CASコマンドでuniq値を指定しながら保存 3. uniq値が一致した場合に限り保存が成功 成功なら1～2間で値が更新されていないこと アトミックな操作ができる が保証される
- 152. ロックを実装すると 上手く動きそうに見える キー バ lock(a); a リュー lock(b); set(a, 1); set(b, 2); b unlock(a); unlock(b);
- 153. ロックを実装すると クライアントが離脱すると破綻する タイムアウトでアンロックしてもデータが一貫 しない 永久にロッ lock(a); キー バ ク a リュー されたまま lock(b); set(a, 1); 離脱 set(b, 2); b unlock(a); unlock(b);
- 154. 提案 キーバリューストア上にトランザクションを実 装 キーバリューストアには手を加えず、クライアント ライブラリとして実現 基本的性能や障害耐性はキーバリューストアの実装に依存 サーバが落ちても大丈夫な分散KVSなら信頼性も安心 クライアントが離脱しても大丈夫 トランザクションを用いて一貫性を保つ トランザクション キーバリュースト ア
- 156. キーバリューストアでの間接化 キーは文字列なのでバリューの中に挿入でき る キー バリュー A B B C A B C
- 157. 複数のキーを格納 複数のキーを格納する事もできる キー バ リュー A ab|cd|ef ab value1 cd value2 ef value3
- 158. 複数のキーを保持 以後はこのように図示 A ab cd ef value1 value2 value3
- 160. トランザクションナルキーバリューペア (TKVP) 通常のキーバリューペア(KVP)をトランザ クションのために拡張したもの key value トランザクション 古い値 新しい値 ステータス oMel1d Sde93A 8Yu4naplE2 key old new status u40F... iLdsa. .. saFASFD... activ value value’ e
- 161. トランザクショナルキーバリューペ ア statusの値によって読み出し方を分岐 commited:Newの値を読み出す abort:Oldの値を読み出す active:競合を解決する(後述) key old new status activ value value’ commited abort e
- 162. トランザクショナルキーバリューペア (TKVP) キーバリューストアにはこのように保存さ れる バ キー リュー Sde93Au40F... key oMel1diLdsa... 8Yu4naplE2saFAS FD… Sde93A u40F... value old oMel1d iLdsa. .. value’new 8Yu4naplE2 activ status saFASFD... e
- 163. トランザクショナルキーバリューペ ア key old new status value value’ commited commited 省略して表記
- 164. トランザクションの実例 トランザクションを用いて Transaction{ set(a, 1); // a=1 set(b, 2); // b=2 set(c, 3); // c=3 } を実現する
- 165. トランザクションの概観 ステータスを初期化 初期化 必要なTKVPを更新 更新 ステータスをコミッ コミット トへ no 成功？ yes 終了
- 166. 初期化 自身のステータスをActiveとしてキーバ リューストアに新たに保存する この際のキーはランダムな文字列を生成す る Transaction{ set(a, 1); // a=1 set(b, 2); // b=2 set(c, 3); // c=3 } set(hoge，active) activ hoge
- 167. トランザクションの概観 ステータスを初期化 初期化 必要なTKVPを更新 更新 ステータスをコミッ コミット トへ no 成功？ yes 終了
- 168. TKVPの最新の値(おさらい) Statusの値によって最新の値が変わる a commited 4 8 commitedならa→8 a abort 4 8 最新の値 abortならa→4
- 169. 更新操作 TKVPの所有権を奪って Transaction{ oldが「これまでの最新の値」 set(a, 1); // a=1 newが「これからの最新の値」 set(b, 2); // b=2 をそれぞれ指すよう書き換える set(c, 3); // c=3 } commitedなら CAS commited a old new aaaa hoge set(fEe09d, 1); cas(a， 4 8 1 [old,fEe09d,hoge]) active 初期化時に保存 abortなら CAS abort したステータス a old new aaaa hoge set(fEe09d, 1); cas(a， 4 8 1 [old,fEe09d,hoge]) active
- 170. 複数のTKVP更新 同一のトランザクションステータスを指す よう複数のTKVPを書き換える Transaction{ set(a, 1); // a=1 set(b, 2); // b=2 1 set(c, 3); // c=3 a } hoge CAS 2 b active hoge CAS 3 c hoge
- 171. トランザクションの概観 ステータスを初期 初期化 化 必要なTKVPを更新 更新 コミット ステータスをコ ミットへ no 成功？ yes 終了
- 172. コミット ステータスがactiveであることを確認して commitedへ書き換える Transaction{ set(a, 1); // a=1 set(b, 2); // b=2 set(c, 3); // c=3 } cas(hoge, commited); Activ hoge commited CAS e
- 173. コミット 書き換えるステータスは必ずキーバリュー ペア一つ 一斉にnewの指している物が最新になる 1 a hoge CAS 個数制限 2 Activ commited なし b e hoge 3 c 最新の値 hoge
- 174. トランザクションの概観 ステータスを初 初期化 期化 更新 必要なKVPを オープンしなが ら更新 コミット no ステータスをコ 成功？ ミット状態へ yes 終了
- 175. アボート コミット時にステータスがabortに書き換えられ ていたらコミット失敗。トランザクションを始 めからやり直す abortに書き変わっているというのはどういう状 況か hoge abort commited
- 176. トランザクショナルキーバリューペ ア ステータスの値によって読み出し方を分岐 commited:Newの値を読み出す abort:Oldの値を読み出す active:競合を解決する key old new status activ value value’ e
- 177. 競合する場合を考える トランザクション hoge Transaction{ set(a, 1); set(b, 2); トランザクション fuga Transaction{ set(b, 999);
- 178. TKVPの所有者がactiveだった場合 所有者のstatusをabortへ書き換える トランザクション TKVPを奪う fuga Transaction{ a hoge set(b, 999); 8 1 aはロール CAS cas(hoge,abort) バック b fuga hoge active リトライ abort CAS b欲し bを獲得 い 7 2 999 最新の値 active 続行
- 179. クライアントが離脱した場合 トランザクション途中で故障などによって 離脱したらいずれ誰かからabortされる。 CAS 離脱 active abort
- 180. 性能測定中…
- 181. 問題点 ゴミが増え続ける もともとDynamicSTMはGC前提 ゴミ active commited a active commited active commited b active c
- 182. 解決策 双方向化により参照カウンタGC ここ実装途中 github.com/kumagi/kvtx2 active commited a active commited active commited b active c
- 184. まとめ Lock-free Stack, Queue, List, Hashmap, SkipList, BtreeとDynamicSTMのアルゴリズム を解説 腑に落ちない所は懇親会で 実装の具体例は僕のGithubや懇親会で ブログ記事で読みたいネタがあったら懇親会で 分散環境に応用しようと取り組んでます