Rustのasync/awaitとスケジューラの話 / rust-async-await

Transcript

1. の と スケジューラの話

2. About Me • • ブロックチェーン技術を軸にプライバシー保護やインターオペラビリティなど の研究開発 @zoom_zoomzo Osuke

3. None

4. LayerXでのRustの使い方 • 暗号プロトコル ◦ 安全性がクリティカル ◦ ライブラリが充実 • システムプログラミング言語として ◦

   プロセッサレベルのメモリ保護機能 の利用 • などを用いてサーバーサイド開発

5. OSS in Rust • ゼロ知識証明ベース ◦ ◦ ◦ •

6. None
7. None

8. std::future::future • ステートマシンの抽象化インターフェース ◦ 将来的に値が確定する計算 • ポーリングモデル（繰り返し ）で状態をできるだ け進めていく •

   すると か を返す ◦ の場合は次の状態へ遷移 ◦ の場合は現在の状態のまま

9. std::task::Context Pending • 次回はどのタイミングでポーリングすればいいのか問題 ◦ が返ってきてすぐまたポーリングするの は 時間の無駄 • （

   の ）でステートマシンの状態遷移が 再開可能になるタイミングの通知を設定 • ナイーブな例 ◦ ▪ の場合、スレッドをブロック ◦ ▪ 時に、スレッドのブロックを解除 Ready

10. example

11. None

12. async/await • 非同期関数内で まで状態を進めていく ◦ を繰り返し実行していく • 非同期処理を同期処理のように扱えるシンタックス

13. async/await • 非同期関数は （再開可能 な計算）のシンタックスシュガー • 非同期関数もステートマシン

14. • 軽量な実行単位 ◦ メモリ消費量・時間コストが スレッドよりも圧倒 的に効率的 • （ スレッドではなく）グリーンスレッド ◦

    ◦ ◦ • それぞれのタスクが独立したステートマシン ◦ で生成 • それぞれの が を持つ ◦ non-blockingであることが重要 Task でタスクアロケーションの効率化

15. Runtime • 非同期計算の実行環境 • に渡さないとランタイムで実行されない ◦ はシステムプログラミング言語として薄く するため言語仕様には組み込まれていない ◦ や

    が有名 • がそれぞれの スレッドで実行する をいい感じに配置 ◦ 公平なスケジューリング ◦ がプリエンプションしない
16. None

17. Scheduler • 単位の実行をよりパフォーマンスが出るように管理 • などでタスク実行キューをロードバランシング ◦ だと 取得時の競合でパフォーマンス低下する Task Task

    Task Task Task exec Task exec

18. Blocking Call • 非同期タスクはすぐに計算が完了することが期待されている • タスクの移動は したところでのみ起こるので、そのポイントにたどり着くまでに 多くの時間を要する場合は他のタスク実行を妨げる可能性がある • 非同期関数内でブロッキングするタスクの呼び出しは大幅なパフォーマンス低下の

    懸念 ◦ 時間のかかるシステムコールの呼び出しなど

19. Pollute runtime... • ブロッキングタスクが同じスレッドで実行される非同期タスクもブロックしてしまう • ランタイム全体のパフォーマンス低下につながる Task Task Task Task

    Task exec Task exec

20. Blocking Calls in tokio • によってブロッキングな呼び出しはバックグラウンドのブロッキン グスレッドへ • 非同期タスクはブロッキングコールの影響を回避 •

    グローバルなスレッドプールなので なライフタイムを持つ必要がある • の代わりに を使うと、現在のスレッドがブロッキ ングスレッドになる ◦ トレイトを要求しない

21. • ブロッキングする可能性のある呼び出し ◦ システムコール ▪ ▪ ◦ バウンドな重い処理 ◦ 外部クレート依存関数の呼び出し

    ◦ 他のタスクと同期する必要がある処理 ◦ • 開発者が呼び出す関数が かどうか考慮しバックグラウンドのブロッキング スレッドへ送る必要がある blocking?

22. gorourtine • スレッド ◦ ブロッキングしている処理を検出 ▪ 開発者は明示的にブロッキングタスクを処理する必要はない ◦ の検出や実行時間の長いタスクのプリエンプションにより、ブロッ キングタスクを他の実行キュー

    グローバルキューにエンキュー Task Task Task Task Task exec Task exec sysmon

23. と の ブロッキング呼び出しに対する対応

24. async-std • 標準ライブラリに かつハイパフォーマンスな非同期処理イン ターフェースを提供 • とは違う独自の非同期ランタイムも提供 • エコシステム ◦

    ◦ ◦

25. async-stdの新しいスケジューラの試み • 時間がかかっているブロッキングな呼び出しをバックグラウンドのスレッドプールへ 自動的に逃す ◦ 実装を見ると少なくとも ごとに 関数を呼び 出す •

    以下のような非同期関数内での時間のかかる呼び出しもスケジューラが暗黙的に ブロッキングスレッドで処理する ◦ 開発者がブロッキングコールを意識しなくてよくなる

26. ランタイム実行のループ内で スレッド生成を行う関数を 呼び出す スレッド タスク実行キュー 処理時間が長いタスクを検出し て新しいスレッドプールへ逃す 部分

27. Auto-detecting blocking calls

28. Benchmark https://async.rs/blog/stop-worrying-about-blocking-t he-new-async-std-runtime/

29. • やっていき • 厳しみ • 一部だけマージ だが、しかし。

30. tokio • 「 」 • プリエンプション：同じタスクを長時間実行し続けてる状態に対する割り込み処理で タスクをスケジューリング ◦ には存在しない ◦

    代わりに、 で が追加 • ：タスクごとのオペレーションの上限カウンタ ◦ オペレーション： ◦ タスクが一定数以上 のオペレーションを行うと自動で ◦ タスクがスイッチしたら カウンタはリセット • あくまで 対策なので、 は依然必要

31. まとめ • も 関数も もステートマシン ◦ や などのランタイム上で状態遷移 ◦ は軽量かつ

    であることがパフォーマンス上重要 • 非同期関数内のブロッキングな呼び出しは今後も開発者が明示的に対処する 必要あり
32. None

33. We are hiring!! • 全ての経済活動をデジタル化していく仲間を募集しています！ https://www.wantedly.com/projects/363053