Day 030 — std::threadによる並行処理基礎（Rc/RefCellがなぜSendでないか）

📚 背景知識（読んでから問題へ）

昨日（Day 029）はthread::spawnが要求するF: Send + 'staticのうち、'static（クロージャが借用したデータより長生きしないか）に焦点を当てました。今日はもう半分の主役、Sendに焦点を当てます。

Sendはマーカートレイト（メソッドを持たず、コンパイラに「この型の所有権を別スレッドへ安全に移動できる」ことだけを伝える印）です。ほとんどの型は自動的にSendを実装しますが、いくつかの型は意図的にSendを実装しません。その代表例がRc<T>（参照カウント式スマートポインタ、Day 46で詳しく学びます）です。

Rc<T>は内部の参照カウンタをアトミック演算なし（ロックなしの単純な整数インクリメント/デクリメント）で更新することで高速化しています。もし複数スレッドが同時に同じRc<T>をclone()すると、カウンタの更新が競合し、カウントがずれて「解放済みメモリへの参照が残る」「二重解放」といったメモリ安全性違反が起こり得ます。Rustはこれを実行時に検出するのではなく、Rc<T>にSendを実装しないことで、複数スレッドをまたぐコード自体をコンパイルさせないという設計を選んでいます。

📝 問題

以下のコードは「4つのスレッドで共有カウンタを1ずつインクリメントし、最終的に4にする」という意図で書かれていますが、コンパイルが通りません。

📋 コピー// このコードはコンパイルエラーになる
use std::cell::RefCell;
use std::rc::Rc;
use std::thread;

fn count_up_wrong() -> i32 {
    let counter = Rc::new(RefCell::new(0));
    let mut handles = Vec::new();

    for _ in 0..4 {
        let counter_clone = Rc::clone(&counter);
        let handle = thread::spawn(move || {
            *counter_clone.borrow_mut() += 1;
        });
        handles.push(handle);
    }

    for handle in handles {
        handle.join().unwrap();
    }

    *counter.borrow()
}

fn main() {
    println!("{}", count_up_wrong());
}

1. 実際に出るコンパイルエラーを読み、Rc<RefCell<i32>>の何がthread::spawnの要求と衝突しているのかを説明してください。
2. スレッド間で安全に共有できる型に差し替えて、正しくコンパイル・実行できるように修正してください（最終出力が4になること）。

🔍 ヒント（段階的開示）

📋 コピーuse std::sync::{Arc, Mutex};
use std::thread;

fn count_up_fixed() -> i32 {
    let counter = Arc::new(Mutex::new(0));
    let mut handles = Vec::new();

    for _ in 0..4 {
        let counter_clone = Arc::clone(&counter);
        let handle = thread::spawn(move || {
            let mut guard = /* ??? Mutexをロックして中身への可変アクセスを得る */;
            *guard += 1;
        });
        handles.push(handle);
    }

    for handle in handles {
        handle.join().unwrap();
    }

    *counter.lock().unwrap()
}

✅ 模範解答

📋 コピー// cargo new day030_send_debug の後、src/main.rs をこの内容で置き換えて
// `cargo run` で検証できます。

use std::sync::{Arc, Mutex};
use std::thread;

// 修正版: Rc<RefCell<i32>> ではなく Arc<Mutex<i32>> を使う。
// Arc はスレッドセーフな(アトミック演算を使う)参照カウント、
// Mutex はロックを介した排他的な内部可変性を提供する。
fn count_up_fixed() -> i32 {
    let counter = Arc::new(Mutex::new(0));
    let mut handles = Vec::new();

    for _ in 0..4 {
        // Arc::clone はカウンタのアトミックなインクリメントのみを行う軽量操作。
        // 複製されるのは「同じヒープ領域を指すハンドル」であって、中身のコピーではない。
        let counter_clone = Arc::clone(&counter);
        let handle = thread::spawn(move || {
            // lock() はそのスレッドが排他ロックを獲得するまでブロックし、
            // MutexGuard<i32> を返す(スコープを抜けると自動でロック解放)。
            let mut guard = counter_clone.lock().unwrap();
            *guard += 1;
        });
        handles.push(handle);
    }

    for handle in handles {
        handle.join().unwrap();
    }

    *counter.lock().unwrap()
}

fn main() {
    let result = count_up_fixed();
    assert_eq!(result, 4);
    println!("count_up_fixed(): {}", result);
    println!("OK");
}

$ cargo run
count_up_fixed(): 4
OK

🪜 Step-by-Step 解説

💡 設計思想・なぜこう書くのか

Rc<T>にSendを実装しない、RefCell<T>にSyncを実装しない、という判断は「危険な可能性がある操作を、デフォルトで塞いでおく」というRustの一貫した設計哲学の表れです。C++のstd::shared_ptrは（参照カウント自体はアトミックですが）中身への同時アクセスを型システムでは一切防いでくれず、「複数スレッドから安全に使えるかどうか」はドキュメントとプログラマの記憶に委ねられます。

Rustでは「型がSend/Syncを実装しているかどうか」というコンパイル時に検証可能な事実に、その判断を落とし込んでいます。今回のエラーは煩わしく感じるかもしれませんが、実際には「あなたが書こうとしたコードは、実行タイミング次第でメモリ破壊を起こす可能性がある」というランタイムでは気づきにくいバグを、コードを書いた瞬間に教えてくれています。

🛑 コンパイルエラーが出た場合

問題文のコードをそのままコンパイルすると、次のようなエラーになります（Rustのバージョンにより文言は多少変わります）。

読み方: E0277は「トレイト境界が満たされていない」ことを示す汎用エラーコードです。1行目の「Rc<RefCell<i32>> cannot be sent between threads safely」が結論、note:の連鎖が「なぜその境界が必要になったか」をthread::spawnの定義まで遡って説明してくれています。注意点として、このエラーメッセージはmoveの追加を提案してきません——Day 029の'staticエラーとは異なり、moveを付けてもRc自体がSendでない事実は変わらないため、コンパイラも「型そのものを変えるしかない」と判断しているからです。

🌐 他言語との比較

🏆 実務での使いどころ

• 複数ワーカースレッドで共有カウンタ・共有キャッシュ・共有設定値にアクセスするサーバーサイドプログラムでは、Arc<Mutex<T>>（または読み取り優先ならArc<RwLock<T>>）がほぼ定番の組み合わせになる
• ライブラリのAPI設計時、ある型にSend/Syncを実装するかどうかの判断（あるいは意図的に実装させないPhantomDataを使ったオプトアウト）は、そのままAPI利用者に対する並行処理安全性の契約になる
• コンパイルエラーE0277 ... cannot be sent between threads safelyは実務のRust開発でも頻出するため、「Rc/RefCellが出てきたらArc/Mutexに置き換える」という反射的な対応をここで身につけておくと後々の学習が楽になる

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: count_up_fixedをstd::sync::atomic::AtomicI32とfetch_addを使ってMutexなしで書き直すとどうなるか調べてみましょう（ロックを使わない「ロックフリー」なカウンタです。詳細はPhase 3後半のlock-freeテーマで扱います）
• 次回予告: 次回はいよいよArc<Mutex<T>>による共有状態管理を本格的に扱います。今日「なぜ必要か」をSend/Syncの観点から理解したので、明日はMutexのロック機構・デッドロックの避け方・RwLockとの使い分けを深掘りします

🎯 自己評価

自分の回答

気づき・メモ