Day 035 — 生ポインタは自動的に!Send。unsafe implで安全性を「証明」する

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

Day 034ではSend/Syncを「型を見て判定する」問題を扱いました。今日はその判定基準を実際に自分の手でコードとして操作します。auto trait（自動導出トレイト）はコンパイラがフィールドを再帰的に見て自動的に付与しますが、生ポインタ*mut T/*const Tのように標準ライブラリが意図的に!Send/!Syncと定義している型を含む構造体は、自動的にスレッド安全でない扱いになります。

この既定を人間の手で上書きするのがunsafe impl Send for MyType {}です。

pub unsafe auto trait Send {}

unsafeが付いている理由は単純で、「コンパイラが自動判定できない領域に、プログラマが責任を持って安全性を保証する」という契約だからです。この契約を書く際は、なぜ安全と言えるかを// SAFETY: ...コメントとして明記するのがRustコミュニティの規約になっています。安全性コメントのないunsafeコードは、コードレビューで真っ先に指摘されるべきアンチパターンです。

📝 問題

以下の2つを実装してください。

Part A: SharedCounter<T>の実装

• 内部はArc<Mutex<Vec<T>>>で保持するジェネリックなコンテナSharedCounter<T>を実装する
• new() -> Self、push(&self, value: T)、len(&self) -> usize、clone_handle(&self) -> Selfを持たせる
• ジェネリック型Tにはスレッドをまたいで安全に扱うために必要なトレイト境界を付ける
• mainで8スレッドを立ち上げ、各スレッドがi32を10個ずつpushし、全join後にlen() == 80であることを確認する

Part B: 生ポインタを含む型とSendの関係

struct RawBuffer {
    ptr: *mut u8,
    len: usize,
}

1. このRawBufferをそのまま別スレッドにmoveしようとするとどんなコンパイルエラーになるか、実際に確認する
2. RawBufferが確保した独立バッファを排他的に所有しており他からエイリアスされていないと仮定し、unsafe impl Send for RawBuffer {}を安全性コメント付きで書く

🔍 ヒント（段階的開示）

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

#[derive(Clone)]
struct SharedCounter<T> {
    inner: Arc<Mutex<Vec<T>>>,
}

impl<T: Send + 'static> SharedCounter<T> {
    fn new() -> Self {
        Self { inner: Arc::new(Mutex::new(Vec::new())) }
    }
    fn push(&self, value: T) {
        self.inner.lock().unwrap().push(value);
    }
    fn len(&self) -> usize {
        self.inner.lock().unwrap().len()
    }
    fn clone_handle(&self) -> Self {
        self.clone()
    }
}

✅ 模範解答

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

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

/// 複数スレッドから安全に値を追加できるコンテナ。
/// Arc>> をラップすることで:
///   - Arc により所有権(参照カウント)をスレッドをまたいで共有できる
///   - Mutex により内部の Vec への同時アクセスを排他制御する
#[derive(Clone)]
struct SharedCounter<T> {
    inner: Arc<Mutex<Vec<T>>>,
}

impl<T: Send + 'static> SharedCounter<T> {
    fn new() -> Self {
        Self { inner: Arc::new(Mutex::new(Vec::new())) }
    }

    fn push(&self, value: T) {
        // lock() が返す LockResult は「他スレッドがパニックしながらロックを
        // 保持していた(=ポイズニング)」場合に Err になる。学習用コードでは
        // unwrap で簡略化するが、本番では Err を伝播させるのが望ましい。
        self.inner.lock().unwrap().push(value);
    }

    fn len(&self) -> usize {
        self.inner.lock().unwrap().len()
    }

    fn clone_handle(&self) -> Self {
        // Arc::clone なので中身のデータはコピーされず、参照カウントだけ増える
        self.clone()
    }
}

fn main() {
    let counter: SharedCounter<i32> = SharedCounter::new();
    let mut handles = Vec::new();

    for worker_id in 0..8 {
        let counter_handle = counter.clone_handle();
        let handle = thread::spawn(move || {
            for i in 0..10 {
                counter_handle.push(worker_id * 10 + i);
            }
        });
        handles.push(handle);
    }

    for handle in handles {
        handle.join().expect("thread panicked");
    }

    assert_eq!(counter.len(), 80);
    println!("total pushed = {}", counter.len());
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn pushes_from_multiple_threads_are_all_recorded() {
        let counter: SharedCounter<i32> = SharedCounter::new();
        let mut handles = Vec::new();

        for worker_id in 0..8 {
            let counter_handle = counter.clone_handle();
            handles.push(thread::spawn(move || {
                for i in 0..10 {
                    counter_handle.push(worker_id * 10 + i);
                }
            }));
        }

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

        assert_eq!(counter.len(), 80);
    }
}

// ---- Part B: 生ポインタと Send ----

struct RawBuffer {
    ptr: *mut u8,
    len: usize,
}

impl RawBuffer {
    fn new(len: usize) -> Self {
        let mut v = std::mem::ManuallyDrop::new(vec![0u8; len]);
        Self { ptr: v.as_mut_ptr(), len }
    }
}

// SAFETY: RawBuffer はヒープ上の連続領域を「排他的に」所有している。
// - この構造体の外部にポインタのコピーは存在しない（Clone を実装していない）
// - 生成後は Drop まで他のコード経路からアクセスされない
// そのため、所有権ごと別スレッドに move しても、元のスレッドと新しいスレッドが
// 同時にこのバッファへアクセスすることはあり得ず、データ競合は起こり得ない。
// よって Send を手動で実装しても安全である。
unsafe impl Send for RawBuffer {}

impl Drop for RawBuffer {
    fn drop(&mut self) {
        unsafe {
            // ManuallyDrop で抜いた分の所有権をここで正しく回収して解放する
            let _ = Vec::from_raw_parts(self.ptr, self.len, self.len);
        }
    }
}

🪜 Step-by-Step 解説

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

Rustの並行性の安全性は「実行時に頑張ってレースを検出する」のではなく、「そもそも危険な操作を型として表現できないようにする」というゼロコスト抽象化の思想に基づく。Send/Syncはランタイムに一切のオーバーヘッドを持たないマーカー（ゼロサイズの制約情報のみ）でありながら、コンパイル時にスレッド安全性の証明を強制する。これは「実行時コストを払わずに安全性を得る」というRustの核心的な設計哲学の並行処理版であり、所有権システムがメモリ安全性を静的に保証するのと全く同じ発想がスレッド安全性にも適用されている。

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

Part Bでunsafe impl Sendを付ける前に、以下のようなコードを書いてRawBufferをそのまま別スレッドにmoveしようとするとコンパイルエラーになります。

fn try_send_raw_buffer() {
    let buf = RawBuffer::new(16);
    thread::spawn(move || {
        println!("len = {}", buf.len);
    });
}

🌐 他言語との比較

Go・Java・C++経験者にとって最大の学びは、「スレッド安全性はドキュメントに書くものではなく、型シグネチャに刻み込まれるものである」という発想の転換です。

🏆 実務での使いどころ

• Webサーバー（axum/actix-web等）でリクエストハンドラ間に共有するアプリケーション状態（DB接続プール、キャッシュ等）はArc<Mutex<T>>やArc<RwLock<T>>で表現するのが定番パターン
• tokio::spawnされたタスク間でデータを受け渡す際も、渡す型がSend + 'staticであることが要求されるため、この境界エラーは非同期プログラミングで日常的に遭遇する
• FFI（C言語ラッパー）や独自メモリ管理を書くライブラリ（独自アロケータ、ゼロコピーパーサー等）では、生ポインタを含む型に対して意図的にunsafe impl Send/Syncを書く場面が頻出する。安全性コメントの書き方はコードレビューで真っ先にチェックされる部分
• !Sendを意図的に維持したい場面（特定のスレッドでしか使ってはいけないハンドル等）では、PhantomData<*const ()>をフィールドに追加してauto traitを意図的に打ち消すテクニックもよく使われる

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: PhantomData<*const ()>を使って、フィールドには生ポインタを持たないが意図的に!Sendにしたい型を作ってみましょう（例: 特定のスレッドに固定したいGUIハンドル）
• 次回予告: async/await基礎 — 協調的マルチタスクとしてのFutureの考え方へ進みます（OSスレッドではなく軽量タスクによる並行性）

🎯 自己評価

自分の回答

気づき・メモ