Tweet
Tweet

Slide 1

Slide 1 text

sync.Mutexの仕組み を理解する Go Conference 2023/06/02

Slide 2

Slide 2 text

自己紹介 Name ● Yoshiki Fujikane (ふじを) Company ● CyberAgent, Inc. 22新卒入社 ● ABEMA バックエンドエンジニア @ffjlabo @ffjlabo

Slide 3

Slide 3 text

● 排他制御を実現するプリミティブ ● 共有リソースに対する競合を起こさず 並行処理を実装できる sync.Mutexとは

Slide 4

Slide 4 text

● 排他制御を実現するプリミティブ ● 共有リソースに対する競合を起こさず 並行処理を実装できる sync.Mutexとは 🤔どうやって実現してるのだろう

Slide 5

Slide 5 text

sync.Mutex の仕組みが知りたい 背景

Slide 6

Slide 6 text

本発表の目的 ● sync.Mutexの内部実装について把握する ● sync.Mutexの仕組みを原理から理解する

Slide 7

Slide 7 text

ʕ◔ϖ◔ʔ> Let’s≡Go $ git checkout 7f1467ff4ddd882acb318c0ffe24fd3702ce75cc

Slide 8

Slide 8 text

● sync.Mutexが実現する排他制御 ● sync.Mutexの構造 ● Lock()の内部実装 ● 実装背景 ● まとめ アジェンダ

Slide 9

Slide 9 text

● sync.Mutexが実現する排他制御 ● sync.Mutexの構造 ● Lock()の内部実装 ● 実装背景 ● まとめ アジェンダ

Slide 10

Slide 10 text

「リソースへアクセスできるのは 1 goroutineのみ」 sync.Mutexが実現する排他制御

Slide 11

Slide 11 text

リソースへのアクセスが複数来ても、1goroutineのみアクセスを許可 sync.Mutexが実現する排他制御 resource G G G Mutex ✅ ❌ ❌

Slide 12

Slide 12 text

1goroutineのみにアクセスを制限するには？ sync.Mutexが実現する排他制御

Slide 13

Slide 13 text

A. 「リソースへのアクセス状況」を記録しておく sync.Mutexが実現する排他制御

Slide 14

Slide 14 text

リソースへアクセスが来た段階でその状態を変数として記録しておく 「リソースへのアクセス状況」を記録 resource G Mutex Locked = false

Slide 15

Slide 15 text

リソースへアクセスが来た段階でその状態を変数として記録しておく 「リソースへのアクセス状況」を記録 resource G Mutex Locked = true ✅

Slide 16

Slide 16 text

別goroutineがアクセスしてきたとき、その変数を元に制御可能！ 「リソースへのアクセス状況」を記録 resource G G G Mutex ✅ ❌ ❌ Locked = true

Slide 17

Slide 17 text

sync.Mutexが実現する排他制御: まとめ ● sync.Mutexの排他制御とは 「リソースへのアクセスを1 gorutineのみに制限する」 こと ● リソースへのアクセス状況を保持しておくことで実現

Slide 18

Slide 18 text

● sync.Mutexが実現する排他制御 ● sync.Mutexの構造 ● Lock()の内部実装 ● 実装背景 ● まとめ アジェンダ

Slide 19

Slide 19 text

2つの状態変数を保持 ● state ○ Mutexの現在の状態を表す ● sema ○ goroutineの待機、解放を管理するためのセマフォ sync.Mutexの内部構造 src/sync/mutex.go

Slide 20

Slide 20 text

state Mutexのロック取得を待機している goroutine（waiter）の数 Mutexの状態 32bit 29bit 3bit src/sync/mutex.go

Slide 21

Slide 21 text

state: Mutexの状態 ● Mutexの状態は3種類 ● 各bitがそれぞれの状態に対応 S W L src/sync/mutex.go

Slide 22

Slide 22 text

state: Mutexの状態 ● mutexLocked ○ Mutexがロックされた状態 S W L src/sync/mutex.go

Slide 23

Slide 23 text

mutexLocked: イメージ 「ロックを獲得したgoroutineが存在する」状態 G G Mutex ✅ ❌

Slide 24

Slide 24 text

state: Mutexの状態 ● mutexWoken ○ 該当Mutexをロックしようとgoroutineが起動した状態 S W L src/sync/mutex.go

Slide 25

Slide 25 text

mutexWoken: イメージ 「ロックしようとするgoroutineが存在する」状態 G G Mutex

Slide 26

Slide 26 text

state: Mutexの状態 ● mutexStarving ○ 該当Mutexを長期間ロックできずにいるgoroutineが存在する状態 ○ 飢餓状態（Starving mode）と呼ばれる S W L src/sync/mutex.go

Slide 27

Slide 27 text

mutexStarving: イメージ 「一定時間以上ロックを待たされているgoroutineが存在する」状態 G G G Mutex ✅ ❌ G もうずっと待ってるんだけどな …

Slide 28

Slide 28 text

● バイナリセマフォ ○ sema == 0 => リソースが占有された状態 ○ sema == 1 => リソースが解放された状態 sema runtimeレベルのロック状況を管理するために利用される（詳細は後ほど） src/sync/mutex.go

Slide 29

Slide 29 text

sync.Mutexの構造: まとめ ● sync.Mutexには2つの状態変数が存在 ○ state: Mutexの様々な状況を表現 ○ sema: バイナリセマフォでruntimeレベルのロック状況を表現

Slide 30

Slide 30 text

sync.Mutexの構造: まとめ ● sync.Mutexには2つの状態変数が存在 ○ state: Mutexの様々な状況を表現 ○ sema: バイナリセマフォでruntimeレベルのロック状況を表現 🤔 なぜ2つも状態変数が存在する？

Slide 31

Slide 31 text

アジェンダ ● sync.Mutexが実現する排他制御 ● sync.Mutexの構造 ● Lock()の内部実装 ● 実装背景 ● まとめ

Slide 32

Slide 32 text

Lock()の内部実装 ● CompareAndSwapを利用して、stateのmutexLockedフラグを更新 ● 更新できればその時点でロックされる src/sync/mutex.go

Slide 33

Slide 33 text

📝 Compare And Swap ● Mutexをアクセス制御する リソースにつき1つ作成 ● それを複数のgoroutineが 参照する resource G Mutex ✅ ❌ ❌ G G 変数の値の更新が競合しないようにatomicな操作で更新 https://pkg.go.dev/sync/atomic#pkg-overview

Slide 34

Slide 34 text

Lock()の内部実装 ● stateの値を更新できなかった場合はlockSlowへ src/sync/mutex.go

Slide 35

Slide 35 text

lockSlow(): 全体像 大まかに以下の3ステップに分かれている ● スピンループ ● stateの再更新 ● semaを用いたロック取得

Slide 36

Slide 36 text

lockSlow(): スピンループ ● 直前のstateがロック状態だった場合にスピンループ src/sync/mutex.go

Slide 37

Slide 37 text

● 「何もしない」という空振り処理を実行する 📝 スピン resource G G Mutex ✅ G 可能な限りロック状態が解除されるのを待つ

Slide 38

Slide 38 text

lockSlow(): stateの再更新 ● 再度stateをロック状態に更新しようと試みる src/sync/mutex.go

Slide 39

Slide 39 text

lockSlow(): stateの再更新 ● ロック状態でも飢餓状態でもない場合はbreak ● 以降はロック状態に更新できても、直前の状態がロック状態の可能性 => 別goroutineがロック中だが更新できた可能性 src/sync/mutex.go

Slide 40

Slide 40 text

lockSlow(): stateの再更新 ● stateのみでは1goroutineのみがロック中か保証できない src/sync/mutex.go

Slide 41

Slide 41 text

lockSlow(): semaを用いたロック取得 ● runtime_SemacquireMutexへ ● semaを用いてruntimeレベルで1goroutineのみがロックした状態を 確保しにいく src/sync/mutex.go

Slide 42

Slide 42 text

ここまでのまとめ ● Lock時はまずはじめにstateを用いて、ロック状態に更新できるか 確認する ● stateをロック状態に更新できたとしても、1goroutineのみが アクセスしていることを保証できない ● stateを用いてもロック状態を保証できない場合は semaを用いてロック状態を確保しようと試みる

Slide 43

Slide 43 text

runtime_SemacquireMutex() ● //go:linkname によってruntime側のprivateメソッドをリンクさせる ● 実体はsync_runtime_SemacquireMutex => semacquire1 src/sync/runtime.go src/runtime/sema.go

Slide 44

Slide 44 text

semacquire1() ● easy caseとharder caseの2パターンの処理が存在 src/runtime/sema.go

Slide 45

Slide 45 text

semacquire1(): easy case ● sema(addr) をロック状態に更新しようと試みる src/runtime/sema.go src/runtime/sema.go

Slide 46

Slide 46 text

semacquire1(): harder case ● waiter countをインクリメント ● cansemacquireを複数回実行 ● waiterとしてenqueue??? ● sleep??? runtimeレベルでgoroutineがどのように動作するか着目する必要あり src/runtime/sema.go

Slide 47

Slide 47 text

goroutine実行過程の概要 X := 3 pow(x) P G G M G G (goroutine): goroutine本体 P (Prosessor): 論理プロセッサ M (Machine): OSスレッド Inspired by https://speakerdeck.com/sakiengineer/sukeziyurakaraxue-bugorantaimu-code-reading-of-runtime-pkg

Slide 48

Slide 48 text

goroutine実行過程の概要 X := 3 pow(x) P G G M G 実行待ちのgoroutineを貯めるqueue 実行中のgoroutine

Slide 49

Slide 49 text

goroutine実行過程の概要 fmt.Println(“Hello”) P G G M G 実行待ちのgoroutineがqueueから取り出され、逐次実行される

Slide 50

Slide 50 text

G semacquire1(): harder case sudog を用意 P G G M G G src/runtime/sema.go

Slide 51

Slide 51 text

● 待ち行列を表現するための構造体 ● チャネルの内部実装にも使われる sudog G prev addr next addr src/runtime/runtime2.go

Slide 52

Slide 52 text

● semtableからsemaのアドレスを元に、rootノードを取得 semacquire1(): harder case src/runtime/sema.go

Slide 53

Slide 53 text

semtable Mutex Mutex G G G G G 各Mutexをロックしようと待機している goroutineの待ち行列 「各Mutexのsemaをロック状態に更新しようと待機する goroutineの待ち行列」の集合 G Mutex Mutex G G G sematable (semaRootの配列) src/runtime/sema.go

Slide 54

Slide 54 text

semacquire1(): harder case P G G M G G Mutex Mutex G G G Mutexのsemaをロック状態に更新しよ うと待機するgoroutineの待ち行列の先 頭ノードを取得！！ G src/runtime/sema.go

Slide 55

Slide 55 text

semacquire1(): harder case ● semaをロック状態に更新しようと試みる src/runtime/sema.go

Slide 56

Slide 56 text

semacquire1(): harder case ● この段階でロック状態に更新できない場合は、 現状ロックを取得できない状態と判断 => ロック更新を一時停止し、goroutineをsleepさせるフェーズへ src/runtime/sema.go

Slide 57

Slide 57 text

semacquire1(): goroutineの一時停止 P G G M G G G G Mutex 現在実行中のgoroutineを待ち行列に追加 src/runtime/sema.go

Slide 58

Slide 58 text

● goparkunlockを呼び出して、 現在のgoroutineを一時停止 & 別goroutineに実行を譲る semacquire1(): goroutineの一時停止 src/runtime/sema.go

Slide 59

Slide 59 text

goparkunlockの挙動 P G G M goroutineを一時停止状態にする G Sleeping… src/runtime/sema.go

Slide 60

Slide 60 text

goparkunlockの挙動 P G G M G Sleeping… 実行待ちのgoroutineを取り出して、起動させる G src/runtime/sema.go

Slide 61

Slide 61 text

Lockの内部実装 まとめ ● まずはじめにstateを用いて、ロック状態に更新できるか確認する ● stateを用いてもロック状態を保証できない場合は semaを用いてロック状態を確保しようと試みる ● semaによるロック取得も無理だった場合、次にスケジューリング されるまでgoroutineは一時停止する

Slide 62

Slide 62 text

Lockの内部実装 まとめ ● まずはじめにstateを用いて、ロック状態に更新できるか確認する ● stateを用いてもロック状態を保証できない場合は semaを用いてロック状態を確保しようと試みる ● semaによるロック取得も無理だった場合、次にスケジューリング されるまでgoroutineは一時停止する 🤔 semaのみ使えばいいのでは？

Slide 63

Slide 63 text

● sync.Mutexが実現する排他制御 ● sync.Mutexの構造 ● Lock()の内部実装 ● 実装背景 ● まとめ アジェンダ

Slide 64

Slide 64 text

なぜわざわざstateとsemaの2つの状態変数を使って 2段階の処理を行っているの？ 実装背景

Slide 65

Slide 65 text

A. コンテキストスイッチを最小限に抑えて効率化するため 実装背景

Slide 66

Slide 66 text

src/runtime/sema.go ● Semaphores in Plan 9. ● https://swtch.com/semaphore.pdf src/runtime/sema.go

Slide 67

Slide 67 text

Semaphores in Plan 9 ● Plan 9におけるセマフォ機構の実装方針などが書かれている ○ Plan 9: かつてRuss Coxらが開発していた教育用OS

Slide 68

Slide 68 text

Semaphores in Plan 9 ● ● u: ユーザ空間上のセマフォ ● k: カーネル空間上のセマフォ 効率を高めるために、競合がない場合は完全にユーザー空間で実行でき、競合を処理するためにカー ネルにのみフォールバックするセマフォ実装があると便利です

Slide 69

Slide 69 text

Semaphores in Plan 9 ● 基本的にユーザ空間上で処理を行う ● 競合が起きた時にだけカーネル空間上で処理を行う ユーザ空間 <-> カーネル空間のコンテキストスイッチを軽減する

Slide 70

Slide 70 text

Semaphores in Plan 9 Goで考えると… ● 基本的にgoroutine空間上で処理を行う ● 競合が起きた時にだけruntime空間上で処理を行う goroutine空間 <-> runtime空間のコンテキストスイッチを軽減する

Slide 71

Slide 71 text

アジェンダ ● sync.Mutexが実現する排他制御 ● sync.Mutexの構造 ● Lock()の内部実装 ● 実装背景 ● まとめ

Slide 72

Slide 72 text

まとめ sync.Mutexは ● 「リソースへのアクセス状況」を管理する役割を持つ ● stateとsemaの2つの状態変数を用いて管理 ● コンテキストスイッチを極力減らす工夫

Slide 73

Slide 73 text

ありがとうございましたʕ◔ϖ◔ʔ