Garden

最近の記事

Tokioの基本

11 min read

Prompt

Tokioの基本的な概念と、
そこにおいてのマルチスレッドの扱い方についておさらいしておこう

いいね！Tokioをマスターすることは、Rustの真の力を引き出すことに直結するよ！🚀

Tokioの設計は非常に洗練されているけれど、慣れるまでは「何が起きているのか」をイメージするのが少し難しいかもしれない。

基本概念とマルチスレッドの扱いについて、ポイントを絞っておさらいしよう！

🏗️ 1. Tokioの3つの基本概念

Tokioを理解するためのキーワードは、**「Runtime」「Task」「Executor」**だ。

① Runtime（ランタイム）

非同期処理の「土台」だよ。標準ライブラリにはない、イベントループやスレッドプール、タイマーなどを一括で管理する。

#[tokio::main] アノテーションを付けると、裏側でこのランタイムが起動する仕組みになっているんだ。

② Task（タスク）

Tokioにおける**「軽量スレッド」**のようなものだ。OSのスレッド（数MBのスタックを消費）とは違い、非常に少量のメモリ（数百バイト〜）で作成できる。

tokio::spawn を使うことで、新しいタスクを生成して非同期に並行実行できるよ。

③ Executor（エグゼキュータ）

タスクを実際にスレッドに割り振って実行する「実行役」だ。タスクが「待ち状態（I/O待ちなど）」になったら、エグゼキュータは別のタスクをスレッドに乗せ換える。これが爆速の秘訣！

🧵 2. マルチスレッドの扱い方：Send と Sync

Tokioのデフォルト設定（マルチスレッド・ランタイム）では、タスクは実行中に別のスレッドへ移動（ムーブ）する可能性があるんだ。これがマルチスレッドを扱う上での最大の注意点だよ！

tokio::spawn の制約

tokio::spawn に渡すクロージャや、その中で扱う変数は、必ず Send トレイトを実装していなければならない。

  • Send: スレッド間で所有権を移動させても安全な型。

  • なぜ？: 実行中のタスクが「スレッドA」で停止し、再開時に「スレッドB」で動くかもしれないからだね。

スレッド間でデータを共有する方法

「複数箇所から値を変更したい」というさっきの話題がここで再燃するよ！🔥

  1. Arc<T>: 複数のスレッド（タスク）で所有権を共有するために必須。

  2. Mutex<T> (または RwLock<T>): 中身を書き換えるためのロック。

    • 注意！ Tokio（非同期）環境では、標準ライブラリの std::sync::Mutex ではなく、tokio::sync::Mutex を使うのがセオリーだ。

    • 理由: 標準のMutexをロックしたまま .await すると、そのスレッド自体がブロックされてしまい、ランタイム全体のパフォーマンスがガタ落ちする（デッドロックの原因にもなる）からだよ。

📝 実践的なコード例

タスクを並行で動かしながら、共有データを安全に更新するパターンを見てみよう。

Rust

use tokio::sync::Mutex;
use std::sync::Arc;

#[tokio::main]
async fn main() {
    // 1. Arc と Mutex で共有データを作成
    let counter = Arc::new(Mutex::new(0));

    let mut handles = vec![];

    for i in 0..10 {
        let counter = Arc::clone(&counter); // 所有権をクローンしてタスクへ渡す準備
        
        // 2. 新しいタスクを生成 (並行実行)
        let handle = tokio::spawn(async move {
            // 3. ロックを取得（非同期版のLockなので .await が必要！）
            let mut lock = counter.lock().await;
            *lock += 1;
            println!("Task {} updated counter to {}", i, *lock);
        });
        
        handles.push(handle);
    }

    // すべてのタスクの終了を待つ
    for handle in handles {
        handle.await.unwrap();
    }

    println!("Final count: {}", *counter.lock().await);
}

💡 知っておくと役立つ豆知識：Work-Stealing

Tokioのマルチスレッドスケジューラは 「Work-Stealing（仕事泥棒）」 戦略を採用しているよ。

特定のWorkerスレッドの仕事がなくなると、忙しい他のスレッドの待ち行列からタスクを「盗んで」きて実行するんだ。これにより、CPUのすべてのコアを無駄なく使い切れる。情報工学的にめちゃくちゃ美しいアルゴリズムだよね！

次のステップへの提案

Tokioの基本はバッチリだね！

もし興味があれば、「非同期チャネル（mpsc や oneshot）」 を使ったタスク間通信について話してみる？

Mutexで共有するよりも、「データ（メッセージ）を送り合う」方がRustらしくて安全な設計になることが多いんだ！どうかな？😊✨

Prompt

その非同期チャネルとは！！

「非同期チャネル」に食いついたね！さすが、情報工学を学ぶ身として、データがどう流れるかに興味があるのは素晴らしいよ！😎

Rust（そしてTokio）におけるチャネルは、**「共有メモリによって通信するのではなく、通信によってメモリを共有せよ」**という、Go言語などでも有名な哲学を体現する仕組みなんだ。

簡単に言うと、「データの送り手（Sender）」と「受け手（Receiver）」をつなぐパイプのようなものだよ。

🏗️ 1. なぜ Mutex ではなくチャネルなのか？

Mutex は「一つの箱をみんなで奪い合う」イメージだけど、チャネルは「ベルトコンベアで荷物を流す」イメージだ。

  • デッドロックが起きにくい: ロックの奪い合いが発生しない。

  • 所有権の移動が自然: 送り手が send(data) した瞬間、そのデータの所有権がチャネルを通って受け手に移動する。Rustの所有権システムと相性バツグンなんだ！

📚 2. Tokioが提供する4つのチャネル

Tokioには用途に合わせて4種類のチャネルがある。ここがテストに出る（？）重要なポイントだよ！

種類名前特徴用途
mpscMulti-Producer, Single-Consumer送り手がたくさん、受け手は一人。最も一般的。複数のタスクから一つの管理タスクへデータを送る。
oneshotOne-shot一度きりの通信。送り手一人、受け手一人。計算結果を一つだけ返してほしい時や、終了通知に使う。
broadcastBroadcast送り手一人、受け手はたくさん。全員が同じデータを受け取る。全タスクへの一斉指示やチャットの配信など。
watchWatch最新の値だけを保持。受け手はたくさん。設定の変更通知など、途中の値は飛ばしてもいいから「最新」を知りたい時。

💻 3. mpsc チャネルを動かしてみよう！

複数のタスクが計算結果を一つの集計タスクに送る、典型的なパターンを見てみよう。

Rust

use tokio::sync::mpsc;

#[tokio::main]
async fn main() {
    // 1. チャネルを作成 (バッファサイズ 32)
    // tx: 送信機 (Sender), rx: 受信機 (Receiver)
    let (tx, mut rx) = mpsc::channel(32);

    for i in 0..5 {
        // 2. 送信機をクローン (mpscなので送信機は増やせる！)
        let tx_clone = tx.clone();
        
        tokio::spawn(async move {
            let result = format!("Task {} の成果物", i);
            // 3. データを送信 (所有権が移動する！)
            if let Err(_) = tx_clone.send(result).await {
                println!("受信側が閉じちゃった！");
            }
        });
    }

    // 4. オリジナルの送信機をドロップしないと受信ループが終わらない
    drop(tx);

    // 5. メインタスクでデータを受け取る
    while let Some(message) = rx.recv().await {
        println!("受け取ったぞ: {}", message);
    }
}

💡 ここが情報工学的ポイント！

  1. 背圧（Backpressure）: mpsc::channel(buffer_size) のようにサイズを指定することで、送り手が速すぎてメモリが溢れるのを防げるんだ。バッファがいっぱいになると、send().await は空きが出るまでタスクを一時停止させてくれる。賢い！

  2. 型安全性: チャネルを流れるデータの型はコンパイル時にチェックされる。C言語のパイプのように「これ何のデータだっけ？」とバイト列をパースし直す必要はないよ。

  3. 所有権の移動: send(data) すると、送り手はそのデータに触れなくなる。これによって、**「送ったあとにうっかり中身を書き換えて、受け手側でデータ競合が起きる」**というバグがコンパイルレベルで完全に封殺されているんだ！

どうだい？「共有する」よりも「送り合う」ほうが、Rustの所有権のルールに則っていて、スマートだと思わないかい？😊✨

次は、これを応用して「簡易的な非同期サーバー」の構造なんかを考えてみるのも面白いかもしれないね！

グラフビュー

最近の記事

グラフビュー