Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
チャネルの仕組み
Search
Kenshi Kamata
April 16, 2018
Programming
6
5.4k
チャネルの仕組み
2018/04/16 golang.tokyo #14 の発表です
Kenshi Kamata
April 16, 2018
Tweet
Share
More Decks by Kenshi Kamata
See All by Kenshi Kamata
500万ユーザーを支える残高の冪等性 / The idempotency of the balance for 5 million Merpay users
knsh14
0
2.8k
Go1.10 strings.Builder の紹介
knsh14
2
1.4k
Go でインタプリタを 書いてみよう
knsh14
0
2.9k
Let’s Create An Interpreter In Go
knsh14
0
140
Go Code Review Comment を翻訳した話
knsh14
0
7.5k
tvOS Leaderboard
knsh14
0
1.2k
Other Decks in Programming
See All in Programming
新世界の理解
koriym
0
130
新しいモバイルアプリ勉強会(仮)について
uetyo
1
250
バイブコーディングの正体——AIエージェントはソフトウェア開発を変えるか?
stakaya
5
880
バイブコーディング × 設計思考
nogu66
0
110
『リコリス・リコイル』に学ぶ!! 〜キャリア戦略における計画的偶発性理論と変わる勇気の重要性〜
wanko_it
1
500
Jakarta EE Meets AI
ivargrimstad
0
670
令和最新版手のひらコンピュータ
koba789
13
7.5k
ライブ配信サービスの インフラのジレンマ -マルチクラウドに至ったワケ-
mirrativ
1
170
No Install CMS戦略 〜 5年先を見据えたフロントエンド開発を考える / no_install_cms
rdlabo
0
480
CEDEC 2025 『ゲームにおけるリアルタイム通信への QUIC導入事例の紹介』
segadevtech
3
840
技術的負債で信頼性が限界だったWordPress運用をShifterで完全復活させた話
rvirus0817
1
1.5k
管你要 trace 什麼、bpftrace 用下去就對了 — COSCUP 2025
shunghsiyu
0
390
Featured
See All Featured
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
36
2.5k
Embracing the Ebb and Flow
colly
86
4.8k
The Language of Interfaces
destraynor
158
25k
Faster Mobile Websites
deanohume
308
31k
Why Our Code Smells
bkeepers
PRO
337
57k
Speed Design
sergeychernyshev
32
1.1k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.3k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.4k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Practical Orchestrator
shlominoach
190
11k
The Straight Up "How To Draw Better" Workshop
denniskardys
235
140k
Transcript
チャネルのしくみ golang.tokyo #14
自己紹介 • 鎌田健史 • KLab 株式会社 ◦ Unity でエディタ拡張書いたり ◦
JS でミニゲーム作ってたり ◦ 最近は Python ツールのサポート • Women Who Go のハンズオンのお手 伝い
資料 動画
帰ってやってほしいこと • GopherCon の発表を調べてみる ◦ 20 分くらいの発表 + 資料 •
実際に channel のソースコードを読んで見る
話したいこと • チャネルのおさらい • チャネルの構造 ◦ バッファありチャネルのデータ保存の仕組み • チャネルとデータの送受信の仕組み ◦
シンプルなやり取り ◦ 処理をブロックするとき
channel のおさらい https://go-tour-jp.appspot.com/concurrency/2 • goroutine 間で競合を起こさずにデータをやり取りする仕組み • Queue を持っていてデータを保存できる •
やり取りするデータの型を持っている goroutine1 goroutine2 chan
channel のおさらい • データのやり取りは FIFO • channel とやり取りできない場合、処理をブロックする • データをやりとり出来るようになると処理を再開する
• close(chan) することで送信側の終了を伝えることができる ◦ range ループで受け取っているときなど
コード例 Playgroundで試す
channel の構造 • チャネルには2種類ある ◦ バッファあり/なし • 実装 ◦ https://golang.org/src/runtime/chan.go#L31
• chan T で生成されるものは実は hchan 構造体のポインタ • メモリ上のヒープ領域に配置される
hchan の構造
バッファありチャネルの内部 • buf ◦ データを持つための配列への unsafe.Pointer • lock ◦ チャネルとデータのやり取りをするときにロックを取る
• sendx ◦ チャネルに送った場合に配列のどこに置かれるか • recvx ◦ チャネルから取り出すときにどの位置から出すか
バッファありチャネル • 生成時に容量を指定するとバッファありチャネル • ch := make(chan string, 10) buf
sendx = 0 lock recvx = 0 ・・・ 0 1 ・・・ 9
バッファありチャネル • 要素を追加すると... buf sendx = 1 lock recvx =
0 0 1 ・・・ 9 ch <- “hello” 0 1 ・・・ 9
バッファありチャネル • 要素を追加すると... buf sendx = 2 lock recvx =
0 0 1 ・・・ 9 0 1 ・・・ 9
バッファありチャネル • 一杯になると... buf sendx = 0 lock recvx =
0 0 1 ・・・ 9 0 1 ・・・ 9
バッファありチャネル • 要素を取りだすと... buf sendx = 0 lock recvx =
1 0 1 ・・・ 9 0 1 ・・・ 9
まとめ • chan T の実態は hchan のポインタ • バッファありチャネルのバッファは FIFO
• その実装はデータを取り出すためのインデックスとデータを受け取 るためのインデックスで実装されている
チャネルの送受信
シンプルな送受信 1. ロックを取る 2. バッファにコピー/バッファからコピー 3. ロック解除
送信 buf sendx = 0 lock recvx = 0 0
1 ・・・ 9 0 1 ・・・ 9
送信 buf sendx = 0 lock recvx = 0 0
1 ・・・ 9 0 1 ・・・ 9
送信 buf sendx = 0 lock recvx = 0 0
1 ・・・ 9 0 1 ・・・ 9
送信 buf sendx = 1 lock recvx = 0 0
1 ・・・ 9 0 1 ・・・ 9
送信 buf sendx = 1 lock recvx = 0 0
1 ・・・ 9 0 1 ・・・ 9
受信 buf sendx = 1 lock recvx = 0 0
1 ・・・ 9
受信 buf sendx = 1 lock recvx = 0 0
1 ・・・ 9
受信 buf sendx = 1 lock recvx = 0 0
1 ・・・ 9
受信 buf sendx = 1 lock recvx = 1 0
1 ・・・ 9
バッファを超える送信をした場合 buf sendx = 0 lock recvx = 0 0
1 ・・・ 9
バッファを超える送信をした場合 buf sendx = 0 lock recvx = 0 0
1 ・・・ 9 送信をブロックしなければいけない
寄り道: goroutine のスケジューリングの話 • M:N thread モデル ◦ M 個の
OS thread で N 個のgoroutine を分担して動かす • それぞれの OS thread に goroutine の Queue を持つ • キリが良いところまで実行して次の goroutine を実行する
G M(OS thread) G G(goroutine) P(Context of Scheduling)
M 個の OS thread G M(OS thread) G G(goroutine) P(Context
of Scheduling) G M(OS thread) G G(goroutine) P(Context of Scheduling) ・・・
参考資料 • Goならわかるシステムプログラミング - Go言語と並列処理(2) • Go のスケジューラ実装とハマりポイント
送信をブロックする 1. スケジューラに対して止めるよう指示する(gopark) 2. OS thread は対象の goroutine を止めて実行から外す 3.
次の goroutine を実行する
G M(OS thread) G G(goroutine) P(Context of Scheduling)
G G M(OS thread) G G(goroutine) P(Context of Scheduling) ch
<- "schlusco"
channel から見たブロック • goroutine を停止する命令を投げる • 今の goroutine と送信用の値を Queue
に保存
buf lock sendq recvq sudog g elem Function01 schlusco
goroutine の再開 • シンプルに取りだす処理を行う • sudog にある要素を取りだして buf に追加 •
sudog にある goroutine を実行待ち状態にする
buf lock sendq recvq sudog g elem Function01 schlusco 0
1 ・・・ 9
buf lock sendq recvq sudog g elem Function01 schlusco 0
1 ・・・ 9
buf lock sendq recvq sudog g elem Function01 schlusco 0
1 ・・・ 9
buf lock sendq recvq sudog g elem Function01 schlusco 0
1 ・・・ 9
G G M(OS thread) G G(goroutine) P(Context of Scheduling)
受信側がブロックする場合 • 基本的に送信側がブロックする場合と逆
G M(OS thread) G G(goroutine) P(Context of Scheduling)
G G M(OS thread) G G(goroutine) P(Context of Scheduling) food
:= <-ch
buf lock sendq recvq sudog g elem Function02 food
goroutine を再開 • 送信処理を行う • sudog にある要素に buf の内容を渡す •
sudog にある goroutine を実行待ち状態にする
buf lock sendq recvq sudog g elem Function02 food 0
1 ・・・ 9
buf lock sendq recvq sudog g elem Function02 food 0
1 ・・・ 9
buf lock sendq recvq sudog g elem Function02 food :=
“sushi” 0 1 ・・・ 9
buf lock sendq recvq sudog g elem Function02 food :=
“sushi” 0 1 ・・・ 9
もっと賢く • sudog の elem は受取先のポインタ • なのでここに直接書いてしまえばOK! • メモリコピーと
lock を取る回数も減って嬉しい
buf lock sendq recvq sudog g elem Function02 food 0
1 ・・・ 9
buf lock sendq recvq sudog g elem Function02 food :=
“sushi” 0 1 ・・・ 9
バッファなしチャネルの話 • 基本的にこれまで話してきたことと同じ • バッファがないので常にブロックが発生する
Select で使う場合 • 全部の channel をロックする • 全部の channel の
sudog に自分を入れて待ち状態にする • 勝った case のところから処理を再開する
まとめ • channel は使い方はシンプル • だけど裏ではしっかり並列処理のための仕組みが動いている • 発表資料はとても勉強になった ◦ Gopher
Con は行けないけど他の資料も見ていきたい