Day 034 — Rc/ArcやCell/Mutexの違いは、Send/Syncという型のプロパティに現れる

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

Day 031〜033ではArc<Mutex<T>>やmpsc::Sender<T>を「型がスレッド間で安全に行き来できる道具」として使ってきました。今日はその裏側、つまりなぜコンパイラはそれが安全だと判断できるのかを扱います。

RustにはSendとSyncという2つのマーカートレイトがあります。マーカートレイトとは、メソッドを1つも持たず、「その型がある性質を満たすこと」だけを表す印です。

pub unsafe auto trait Send {}
pub unsafe auto trait Sync {}

• Send: その型の値を別のスレッドに所有権ごと移動しても安全であることを示す
• Sync: その型への共有参照（&T）を複数スレッドから同時に触っても安全であることを示す（T: Sync ⇔ &T: Sendという関係になっている）

重要なのはauto traitという部分です。多くのトレイトはimpl Trait for Typeと明示的に書かないと実装されませんが、Send/Syncはコンパイラが型の構造を見て自動的に判定します。構造体・enumのフィールドが全てSendならその型も自動的にSendになり、1つでも!Sendなフィールドがあれば全体も!Sendになります。

unsafe auto traitとある通り、型によっては手動でこの自動判定を上書きすることもできます。Rc<T>は中身が全てSendな型（例えばRc<i32>）であっても、あえてSend/Syncを実装しないよう設計されています。理由は、Rcの参照カウントの増減（+= 1 / -= 1）が非アトミック演算だからです。2つのスレッドが同時にRc::cloneすると、カウンタの更新がデータ競合を起こし、カウントがずれて二重解放（use-after-free）につながる可能性があります。一方Arc（Atomically Reference Counted）は、その名の通りカウンタの増減にアトミック命令を使うため、複数スレッドから同時にcloneしても安全であり、Send/Syncになれます。

📝 問題

以下の6つの型について、Sendか・Syncか（あるいは両方か、どちらでもないか）を判定し、それぞれ理由を説明してください。

1. Arc<i32>
2. Arc<Mutex<i32>>
3. Cell<i32>（およびRefCell<i32>）
4. Mutex<Cell<i32>>
5. Mutex<Rc<i32>>
6. Rc<i32>

要件1（判定）: 上記6つそれぞれについて Send/Sync の有無を判定し、理由を一言で説明してください。特に3と4の対比（Cell<i32>自体は!Syncなのに、Mutex<Cell<i32>>はSyncになれるのはなぜか）と、4と5の対比（同じMutex<T>でもTがCell<i32>かRc<i32>かで結果が変わるのはなぜか）に注目してください。

要件2（実装）: fn assert_send<T: Send>() {} と fn assert_sync<T: Sync>() {} という2つの関数を定義し、要件1で「Send/Syncである」と判定した型についてはこれらの関数を実際に呼び出してコンパイルが通ること自体を証明するコードを書いてください（「Send/Syncでない」と判定した型は呼び出しをコメントアウトし、理由をコメントで残してください）。

要件3（実行時デモ）: Arc<Mutex<Cell<i32>>>を4つのスレッドで共有し、それぞれのスレッドがロックを取得して内部のCell<i32>の値をインクリメントするプログラムを書き、最終的な合計値が期待通りになることをassert_eq!で検証してください。

🔍 ヒント（段階的開示）

unsafe impl<T: ?Sized + Send> Send for Mutex<T> {}
unsafe impl<T: ?Sized + Send> Sync for Mutex<T> {}

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

fn assert_send<T: Send>() {}
fn assert_sync<T: Sync>() {}

fn main() {
    assert_send::<Arc<i32>>();
    assert_sync::<Arc<i32>>();

    assert_send::<Mutex<Cell<i32>>>();
    assert_sync::<Mutex<Cell<i32>>>();

    // assert_sync::<Cell<i32>>(); // ← ここでコンパイルエラーが出るはず。
                                   //    実際に一度コメントを外してエラーメッセージを読んでみましょう
}

✅ 模範解答

📋 コピー// cargo new day034_send_sync の後、src/main.rs をこの内容で置き換えて
// `cargo run` で検証できます（外部クレート依存なし、標準ライブラリのみ）。

use std::cell::{Cell, RefCell};
use std::sync::{Arc, Mutex};
use std::thread;

// コンパイル時に「この型がSendか/Syncか」を検査するための小道具。
// 呼び出せた時点で、その型がSend/Syncであることがコンパイラによって証明される。
fn assert_send<T: Send>() {}
fn assert_sync<T: Sync>() {}

fn main() {
    // ① Arc<i32>: Send + Sync（i32自体がSend+Syncなので、Arcもそれを引き継ぐ）
    assert_send::<Arc<i32>>();
    assert_sync::<Arc<i32>>();

    // ② Arc<Mutex<i32>>: Send + Sync（Mutexが排他制御を提供するのでSyncになれる）
    assert_send::<Arc<Mutex<i32>>>();
    assert_sync::<Arc<Mutex<i32>>>();

    // ③ Cell<i32> / RefCell<i32>: Sendだが!Sync
    //    (UnsafeCell<T>を内部に持つため、ロックなしの内部可変性はスレッド間で共有できない)
    assert_send::<Cell<i32>>();
    assert_send::<RefCell<i32>>();
    // assert_sync::<Cell<i32>>();    // ← これはコンパイルエラーになる（後述）
    // assert_sync::<RefCell<i32>>(); // ← 同上

    // ④ Mutex<Cell<i32>>: Send + Sync になる
    //    MutexはT: Sendでさえあれば、TがSyncでなくてもSyncを付与する
    assert_send::<Mutex<Cell<i32>>>();
    assert_sync::<Mutex<Cell<i32>>>();

    // ⑤ Mutex<Rc<i32>>: SendでもSyncでもない
    //    RcはSendでないため、Mutexで包んでも「T: Send」の前提が満たせない
    // assert_send::<Mutex<Rc<i32>>>(); // ← コンパイルエラー（後述）
    // assert_sync::<Mutex<Rc<i32>>>(); // ← コンパイルエラー（後述）

    // ⑥ Rc<i32>: SendでもSyncでもない
    // assert_send::<Rc<i32>>(); // ← コンパイルエラー
    // assert_sync::<Rc<i32>>(); // ← コンパイルエラー

    println!("assert_send / assert_sync: 全てのコンパイル時アサーションを通過しました");

    // ── 実行時デモ: Arc<Mutex<Cell<i32>>> はスレッド間で安全に共有できる ──
    let shared = Arc::new(Mutex::new(Cell::new(0)));
    let mut handles = vec![];
    for i in 0..4 {
        let shared = Arc::clone(&shared);
        handles.push(thread::spawn(move || {
            let guard = shared.lock().unwrap();
            let prev = guard.get();
            guard.set(prev + i);
        }));
    }
    for h in handles {
        h.join().unwrap();
    }
    let total = shared.lock().unwrap().get();
    println!("4スレッドでCellを更新した合計: {total}（0+1+2+3=6のはず）");
    assert_eq!(total, 6);
    println!("OK: Mutexの排他制御により、!SyncなCell<i32>でも安全にスレッド間共有できた");
}

$ rustc -O main.rs -o day034 && ./day034   # (1回目)
assert_send / assert_sync: 全てのコンパイル時アサーションを通過しました
4スレッドでCellを更新した合計: 6（0+1+2+3=6のはず）
OK: Mutexの排他制御により、!SyncなCell<i32>でも安全にスレッド間共有できた

# 2回目・3回目も出力は完全に一致（合計値6は決定的）

🪜 Step-by-Step 解説

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

Send/Syncが体現しているのは、Rustの「安全性をランタイムの規律ではなく型システムに埋め込む」という一貫した設計思想です。C++やJavaでは「このオブジェクトはスレッドセーフか」はドキュメントに書かれた約束にすぎず、破っても即座にはコンパイラも実行環境も教えてくれません。Rustではこの約束がSend/Syncという型のプロパティになっているため、約束を破るコード（!Sendな値をthread::spawnに渡す等）はそもそもコンパイルが通りません。

さらに興味深いのは、Send/Syncが「構造体を作った瞬間に自動で決まる」という設計です。開発者は普段、自分の作った型がSendかどうかを意識する必要すらありません（フィールドが全てSendならその構造体も自動的にSendになります）。意識すべきタイミングは、Rc/RefCellのような「意図的にSend/Syncを実装しない」型を使うときだけです。これは「デフォルトで安全、危険なことをするときだけ明示的にオプトインする」というRust全体を貫く設計哲学（unsafeブロックの考え方とも共通）の並行処理版と言えます。

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

要件2で「Send/Syncでない」と判定した組み合わせを実際にコメントアウトせずに呼び出すと、次のような実際のコンパイルエラーが出ます（rustc 1.96.0で実機検証済み）。

Cell<i32>をassert_syncに渡した場合:

注目すべきはnoteの1行です。コンパイラが「代わりにRwLockかAtomicI32を使え」と具体的な代替案まで提示してくれています。これはエラーメッセージが単なる「ダメです」ではなく、次に何をすべきかまで教えてくれるRustのエラーメッセージ設計の良さが表れている例です。

Rc<i32>をthread::spawnのクロージャにmoveで渡した場合:

Mutex<Rc<i32>>をassert_sendに渡した場合、エラーメッセージはMutex<Rc<i32>>ではなく最終的にRc<i32>を名指しします（= note: required for std::sync::Mutex<Rc<i32>> to implement Sendという橋渡しの行が挟まる形）。ラップしている外側の型（Mutex）ではなく、根本原因の内側の型（Rc）までコンパイラが遡って教えてくれる点は、複雑にネストした型のデバッグで非常に助かります。

🌐 他言語との比較

🏆 実務での使いどころ

• ライブラリ設計時の意図的な制約: 自作の型を「あえてスレッドをまたがせたくない」場合（例: FFIで扱うOSリソースのハンドル、シングルスレッド前提のキャッシュ）は、PhantomData<*const ()>のような!Send/!Syncなマーカーフィールドを持たせることで、コンパイラに「この型はスレッドをまたげない」と強制させる設計がよく使われる
• Arc<Mutex<T>> vs Rc<RefCell<T>>の選択: シングルスレッドのGUIアプリやシングルスレッドのasyncランタイム（tokio::task::LocalSet等）ではRc<RefCell<T>>の方がアトミック操作やロック取得のオーバーヘッドがなく高速。マルチスレッドで共有する必要があるかどうかを最初に見極めることが、無駄なロックコストを避ける第一歩になる
• コンパイルエラーがそのまま設計レビューになる: 「この型をArcで包んでスレッド間共有しようとしたらコンパイルが通らなかった」という経験は、実は「この型の設計にスレッド安全でない要素が紛れ込んでいた」というレビュー結果そのもの。Rustではこのレビューがコンパイラによって強制的に行われる

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: PhantomData<Rc<()>>を構造体に含めることで、その構造体を意図的に!Send/!Syncにするテクニックを試してみましょう。「本来はSendにできるはずの型を、設計上あえて!Sendにする」判断がなぜ必要になるか（例: OSのスレッドローカルなリソースをラップする型）を考えてみてください
• 次回予告: 次回はasync/await基礎を扱います。これまでのstd::threadベースの並行処理から一歩進み、「協調的マルチタスク」としてのFutureの考え方と、なぜasync fnが舞台裏で状態機械（ステートマシン）にコンパイルされるのかを見ていきます

🎯 自己評価

自分の回答

気づき・メモ