コード読解演習 Step 4【現場鑑識】：非同期・マルチスレッド競合コードの読解術

### 並行処理コード鑑識の「3大スキャン・チェックリスト」

1. **チェック1：共有可変状態（Shared Mutable State）の特定**:
- どのメンバ変数が複数スレッドから読み書きされるか？（キュー、カウンタ、完了フラグなど）
- 「読み取り（Read）」だからといって mutex なしでアクセスしていないか？（書き込み中の読み取りも立派なデータ競合）
2. **チェック2：ロック獲得順序（Lock Acquisition Order）の統一**:
- 関数Aで `Lock(M1) -> Lock(M2)` の順で取っているのに、関数Bで `Lock(M2) -> Lock(M1)` と逆順で取っていないか？（デッドロックの確定フラグ）
3. **チェック3：同期プリミティブの正当性**:
- `std::condition_variable` を呼ぶ際、`while` ループで条件を再確認しているか？（スプリアス・ウェイクアップ対策）
- `std::atomic` に頼りすぎて、複数変数のアトミック性が崩れていないか？

• 「読み取り専用だからロック不要」は最大の幻想: C++のメモリモデルにおいて、片方のスレッドが書き込んでいる最中に別のスレッドが非ロックで読み出すと「未定義動作（Undefined Behavior）」となり、値の破損やクラッシュが必発します。

#include <iostream>
#include <vector>
#include <string>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <queue>

struct Job {
    int id;
    std::string payload;
};

class AsyncJobQueue {
private:
    std::queue<Job> m_queue;
    std::mutex m_queueMutex;
    std::mutex m_logMutex;
    std::condition_variable m_cv;
    
    bool m_isRunning = true;
    int m_processedCount = 0; // 処理済みジョブ数

public:
    // ジョブの追加（メインスレッドから呼ばれる）
    void pushJob(Job job) {
        {
            std::lock_guard<std::mutex> lock(m_queueMutex);
            m_queue.push(std::move(job));
        }
        m_cv.notify_one();
    }

    // ワーカースレッドのメインループ
    void workerLoop(int workerId) {
        while (m_isRunning) {
            Job currentJob;
            {
                std::unique_lock<std::mutex> qLock(m_queueMutex);
                m_cv.wait(qLock, [this]() { return !m_queue.empty() || !m_isRunning; });

                if (!m_isRunning && m_queue.empty()) {
                    break;
                }

                currentJob = std::move(m_queue.front());
                m_queue.pop();
            }

            // ジョブの実行
            executeJob(workerId, currentJob);

            // ⚠️ 疑問点A：排他制御のないカウンタ加算？
            m_processedCount++;
        }
    }

    // ジョブ実行（ログ出力付き）
    void executeJob(int workerId, const Job& job) {
        // ⚠️ 疑問点B：ロック順序は安全か？
        std::lock_guard<std::mutex> logLock(m_logMutex);
        std::cout << "[Worker " << workerId << "] Job " << job.id << " executed: " << job.payload << std::endl;
    }

    // ジョブキューの統計ダンプ
    void dumpStats() {
        // ⚠️ 疑問点C：m_logMutex を取った後に m_queueMutex を取る？
        std::lock_guard<std::mutex> logLock(m_logMutex);
        std::lock_guard<std::mutex> qLock(m_queueMutex);

        std::cout << "=== Queue Stats ===" << std::endl;
        std::cout << "Remaining: " << m_queue.size() << ", Completed: " << m_processedCount << std::endl;
    }

    // 処理済み件数の取得
    int getProcessedCount() const {
        return m_processedCount; // ⚠️ 疑問点D：ロックなしで直接読めるのか？
    }

    void stop() {
        {
            std::lock_guard<std::mutex> lock(m_queueMutex);
            m_isRunning = false;
        }
        m_cv.notify_all();
    }
};

• コードレビュー時の視線の動かし方: まずメンバ変数一覧を見て「ミューテックスの数」を確認します。2個以上のミューテックスがある場合、必ず「複数同時にロックしている箇所」を探して順序の不一致（AB-BAデッドロック）を疑います。

• 1. m_queue（std::queue）
• 2. m_processedCount（int）
• 3. m_queueMutex（std::mutex）
• 4. m_cv（std::condition_variable）

正解と解説を見る

正解：m_processedCount（int）
正解です！m_processedCount は通常の int であり、workerLoop 内でロックなしに `m_processedCount++` されています。複数スレッドが同時にインクリメントすると競合（Data Race）が発生します。

• 1. スレッドの数が多すぎること
• 2. 複数のミューテックスを獲得する順序が、関数やスレッドごとに異なっており、互いに相手のロック解放を待ち合ってしまうこと
• 3. std::lock_guard ではなく std::unique_lock を使っていること
• 4. while ループを使っていること

正解と解説を見る

正解：複数のミューテックスを獲得する順序が、関数やスレッドごとに異なっており、互いに相手のロック解放を待ち合ってしまうこと
正解です！例えばスレッドAが M1 を取ってから M2 を待っている間に、スレッドBが M2 を取ってから M1 を待つと、永久にお互いが進まなくなる「循環待ち（デッドロック）」が発生します。

• 1. volatile int m_processedCount に変更する
• 2. std::atomic<int> m_processedCount = 0; に変更する
• 3. すべてのスレッドをシングルスレッドにする
• 4. sleep_for(1ms) をインクリメントの前に入れる

正解と解説を見る

正解：std::atomic<int> m_processedCount = 0; に変更する
正解です！C++において volatile はスレッド安全性を保証しません。`std::atomic<int>` を使用することで、ハードウェアの原子的命令（CPUアトミック加算）によりロック不要かつ最高速でデータ競合を完全排除できます。

• 1. OSの都合で notify されていないのにスレッドが勝手に目覚めてしまう現象があるため、条件が真になるまで自動で再待機させるため
• 2. コンパイルエラーを防ぐための形式的なおまじない
• 3. メモリを節約するため
• 4. 関数の実行速度を2倍にするため

正解と解説を見る

正解：OSの都合で notify されていないのにスレッドが勝手に目覚めてしまう現象があるため、条件が真になるまで自動で再待機させるため
正解です！マルチスレッド環境では、OSのシグナル配送の都合などで通知がないのに起きてしまう「スプリアス・ウェイクアップ（虚偽の起床）」が起きます。述語を渡すことで、条件を満たしていない場合は自動的に再スリープに入りバグを防ぎます。