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
【Crystal】Concurrency
Search
at_grandpa
July 18, 2018
Technology
960
3
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
【Crystal】Concurrency
crystal.tokyo #7 での発表資料です。
https://crystal.connpass.com/event/93629/
at_grandpa
July 18, 2018
More Decks by at_grandpa
See All by at_grandpa
技術書典5でチャレンジしたあれこれ
atgrandpa
3
2k
CSS組版おもしろい!
atgrandpa
1
340
Rubyを好きになった過程
atgrandpa
3
1.6k
技術同人誌を執筆して得たこと
atgrandpa
3
1.7k
【Crystal】Macroについて
atgrandpa
3
1.6k
初のサークル参加で気づいた小さなこと
atgrandpa
0
520
Other Decks in Technology
See All in Technology
1.5時間を無駄にして学んだwsl2におけるaptとsnapの選択と仕組み
yosaka0123
0
460
サービス内で複数のOP・ASを連鎖させる(OAuth/OIDC Numa (Immersion) Workshop 2026)
oidfj
PRO
0
350
EUDIWの枠組みを出発点に民間エコシステムの在り方を考える(OAuth/OIDC Numa (Immersion) Workshop 2026)
oidfj
PRO
0
340
Windows の互換機能 - 古いプログラムはなぜ動作できるのか
murachiakira
PRO
0
130
「面白い!」を信じ抜け。激動の時代を貫く、オンリーワン・エンジニアの条件
kizawa2020
2
400
みてねにおけるAI-DLC導入活動とAIドリブン開発の現在地/JAWS-UG AI-DLC #2
isaoshimizu
2
280
Introduction to Sansan, inc / Sansan Global Development Center, Inc.
sansan33
PRO
0
3.2k
RapidCopy2 Matrix I/Oエンジンによるファイルコピーソフトウェアの設計と実装
kengosawa2
1
480
ClaudeCodeでセキュリティ監視業務を半自動化_1年の運用でわかったAIに任せる設計の5つのポイント
kintotechdev
3
900
紙 to デジタル
ichien178
0
370
Oracle AI Databaseデータベース・サービス: BaseDB/ExaDB-Dの可用性
oracle4engineer
PRO
1
960
形式手法特論:Hyperproperty とモデル検査 #kernelvm / Kernel VM Study Tokyo 19th
ytaka23
1
880
Featured
See All Featured
Principles of Awesome APIs and How to Build Them.
keavy
128
18k
The Pragmatic Product Professional
lauravandoore
37
7.4k
30 Presentation Tips
portentint
PRO
1
380
Git: the NoSQL Database
bkeepers
PRO
432
67k
[RailsConf 2023] Rails as a piece of cake
palkan
59
6.9k
Evolving SEO for Evolving Search Engines
ryanjones
0
270
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
The Cult of Friendly URLs
andyhume
79
7k
More Than Pixels: Becoming A User Experience Designer
marktimemedia
3
510
Exploring anti-patterns in Rails
aemeredith
3
480
Tell your own story through comics
letsgokoyo
1
1k
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
74
42k
Transcript
Concurrency 2018.07.18 @at_grandpa Crystal.tokyo #7 in 渋谷
@at_grandpa
圧倒亭グランパのブログ
Concurrency
✔ Concurrency の雰囲気を話します ✔ 細かい syntax などはドキュメント参照
None
“as in Go or Clojure” ✔ Go の goroutine/channel とほぼ同じ
終了!
Concurrency の中身を ちょっと覗いてみましょう
サンプルコード ✔ 並行処理 ✔ 各処理からの値の取得
None
String型のChannelをインスタンス化
2つのFiberを生成
Channel経由で値を取得
2018-07-18 08:12:50 +09:00 start 2018-07-18 08:12:50 +09:00 [fiber 1] start
2018-07-18 08:12:50 +09:00 [fiber 2] start 2018-07-18 08:12:55 +09:00 [top level] value: send from fiber 1 2018-07-18 08:12:55 +09:00 [fiber 1] end 2018-07-18 08:13:00 +09:00 [top level] value: send from fiber 2 2018-07-18 08:13:00 +09:00 end
2018-07-18 08:12:50 +09:00 start 2018-07-18 08:12:50 +09:00 [fiber 1] start
2018-07-18 08:12:50 +09:00 [fiber 2] start 2018-07-18 08:12:55 +09:00 [top level] value: send from fiber 1 2018-07-18 08:12:55 +09:00 [fiber 1] end 2018-07-18 08:13:00 +09:00 [top level] value: send from fiber 2 2018-07-18 08:13:00 +09:00 end ・並行に動いている ・値も取れている
どういう仕組みで動いているか
✔ Fiber ✔ Runtime Scheduler ✔ Event Loop ✔ Channel
✔ IO::Syscall Concurrencyを理解するポイント
Fiber ✔ Process ⊃ Thread ⊃ Fiber ✔ 協調マルチタスク -
Fiber自ら、処理を他のFiberに委譲する - 1つのFiberが固まるとシステム全体が固まる ✔ Crystalの処理は全てFiberで行われている - 「Main Fiber」でメインの処理を実行している
Runtime Scheduler ✔ Fiberの切り替えを担当 ✔ クラス変数にFiberのqueueを持っている - @@runnables = Deque(Fiber).new
- 実行可能Fiberのqueue ✔ Scheduler.rescheduleで切り替え
Event Loop ✔ I/O処理の委譲先 ✔ 委譲している間に別のFiberを実行できる ✔ I/O処理が終了したら委譲元のFiberに移る
Channel ✔ Fiber間のデータのやりとり ✔ 送信元Fiberや受信先Fiberを保持 - @senders = Deque(Fiber).new -
@receivers = Deque(Fiber).new ✔ 送受信時にFiberを切り替え - Runtime Scheduler を使う
IO::Syscall ✔ 以下でincludeされている - Crystal::System::FileDescriptor - Socket ✔ read/writeでFiber切り替え -
Runtime Scheduler を使う ほぼ全てのI/Oを網羅
実際の動き追う
None
Channelをインスタンス化
・Fiber1を定義 ・Runtime Scheduler の 実行可能Fiberのqueueに Fiber1が enqueue される
concurrency.cr ・Fiber1を定義 ・Runtime Scheduler の 実行可能Fiberのqueueに Fiber1が enqueue される
・Fiber2を定義 ・Runtime Scheduler の 実行可能Fiberのqueueに Fiber2が enqueue される
・実際の処理はここから開始 ・Top Level のコードは 「Main Fiber」で動いている ・Channelの送受信時には Fiberの切り替えが行われる
・実際の処理はここから開始 ・Top Level のコードは 「Main Fiber」で動いている ・Channelの送受信時には Fiberの切り替えが行われる ・Runtime Scheduler
の 実行可能Fiberのqueue からshift ・Fiber1に処理が移る
・Fiber1に処理が移った
・sleep
concurrency.cr
concurrency.cr fiber.cr
concurrency.cr fiber.cr ・Event Loop に処理を委譲 ・Runtime Scheduler で queueの次のFiber切り替え
concurrency.cr fiber.cr ・Event Loop に処理を委譲 ・Runtime Scheduler で queueの次のFiber切り替え ・Fiber2へ移る
・Fiber2に処理が移った
・同じくFiber切り替え ・しかし、もう 実行可能Fiberのqueueには Fiberが存在しない ・I/O処理を待機するしかない
待機中 . . .
・Event Loop が sleep 5 の 終了を検知 ・処理中のFiberが他にいないので Fiber1の処理が再開される
・Channelに値を送信 ・sendの場合はreceiveを 呼んだFiberに切り替え ・Main Fiber に切り替わる ・このとき、sendしたFiberを Schedulerのqueueにenqueue
・Channelに値を送信 ・sendの場合はreceiveを 呼んだFiberに切り替え ・Main Fiber に切り替わる ・このとき、sendしたFiberを Schedulerのqueueにenqueue
・受信された値を表示
・Schedulerの 実行可能Fiberのqueueを元に Fiberの切り替え ・queueにはsendした際に enqueueされたFiber1が入っている
・Schedulerの 実行可能Fiberのqueueを元に Fiberの切り替え ・queueにはsendした際に enqueueされたFiber1が入っている ・Fiber1が再開
・値の表示
・Fiber1のブロックが終了 ・Fiberの切り替えが発生 ・しかし、Schedulerの queueには実行可能Fiberが 存在しない
待機中 . . .
・Event Loop が sleep 10 の 終了を検知 ・処理中のFiberが他にいないので Fiber2に処理が戻る
・Channelに値を送信 ・sendの場合はreceiveを 呼んだFiberに切り替え ・Main Fiber に切り替わる ・このとき、sendしたFiberを Schedulerのqueueにenqueue
・Channelに値を送信 ・sendの場合はreceiveを 呼んだFiberに切り替え ・Main Fiber に切り替わる ・このとき、sendしたFiberを Schedulerのqueueにenqueue
・受信された値を表示
・そのまま終了
・そのまま終了 ・ここは通らない
・そのまま終了 ・ここは通らない 2018-07-18 08:12:50 +09:00 start 2018-07-18 08:12:50 +09:00 [fiber
1] start 2018-07-18 08:12:50 +09:00 [fiber 2] start 2018-07-18 08:12:55 +09:00 [top level] value: send from fiber 1 2018-07-18 08:12:55 +09:00 [fiber 1] end 2018-07-18 08:13:00 +09:00 [top level] value: send from fiber 2 2018-07-18 08:13:00 +09:00 end [fiber 2] end は表示されてない
複雑!
とはいえ ✔ Concurrencyに必要な役者を知る - Fiber, Runtime Scheduler, Event loop, Channel
✔ Fiberが切り替わるタイミングを知る - I/Oの場合 - 実行可能Fiber-queueからshift - receiveの場合 - 実行可能Fiber-queueからshift - sendしたFiberをqueueにenqueue - sendの場合 - receiveしたFiberに切り替え これらを知るだけで、だいぶ変わる
まとめ
✔ 並行処理 ✔ Concurrencyに必要な役者を知ろう ✔ Fiberを切り替えるタイミングを知ろう Concurrency
✔ 立て続けにsendされたらどうなるの? - sendされた値もqueueに保存される - receiveを呼ぶ度にqueueからshift ✔ Fiber内でI/O以外の重い処理があったら? - 委譲できない処理はそのまま処理される
- その処理が終わるまで他のFiberは実行できない ✔ 入れ子spawnとかどうなるんだろう? - \(^o^)/ まだまだあるよ
Happy Crystalling ! fin