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.3k
チャネルの仕組み
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.7k
Go1.10 strings.Builder の紹介
knsh14
2
1.3k
Go でインタプリタを 書いてみよう
knsh14
0
2.9k
Let’s Create An Interpreter In Go
knsh14
0
120
Go Code Review Comment を翻訳した話
knsh14
0
7.3k
tvOS Leaderboard
knsh14
0
1.2k
Other Decks in Programming
See All in Programming
自力でTTSモデルを作った話
zgock999
0
110
Rubyと自由とAIと
yotii23
6
1.8k
コミュニティ駆動 AWS CDK ライブラリ「Open Constructs Library」 / community-cdk-library
gotok365
2
250
Amazon Bedrockマルチエージェントコラボレーションを諦めてLangGraphに入門してみた
akihisaikeda
1
100
Django NinjaによるAPI開発の効率化とリプレースの実践
kashewnuts
1
280
『テスト書いた方が開発が早いじゃん』を解き明かす #phpcon_nagoya
o0h
PRO
9
2.5k
技術を改善し続ける
gumioji
0
140
「個人開発マネタイズ大全」が教えてくれたこと
bani24884
1
250
DRFを少しずつ オニオンアーキテクチャに寄せていく DjangoCongress JP 2025
nealle
2
280
読まないコードリーディング術
hisaju
0
110
Rails 1.0 のコードで学ぶ find_by* と method_missing の仕組み / Learn how find_by_* and method_missing work in Rails 1.0 code
maimux2x
1
250
Learning Kotlin with detekt
inouehi
1
140
Featured
See All Featured
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
193
16k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Music & Morning Musume
bryan
46
6.4k
Being A Developer After 40
akosma
89
590k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
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 は行けないけど他の資料も見ていきたい