![更新操作
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](https://image.slidesharecdn.com/lock-freesafe-111210041913-phpapp02/85/Lock-free-safe-169-320.jpg)
冬の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や懇親会で ブログ記事で読みたいネタがあったら懇親会で 分散環境に応用しようと取り組んでます