レガシー第17章：レガシーマルチスレッドとロックフリータスクキュー

• 16.6ミリ秒の絶対防衛線: 60FPSのゲームでは、1フレームあたり16.6ミリ秒を超過する処理をメインループに直接書いてはならない。
• メインスレッドとワーカースレッドの責務分離: メインスレッドは描画・入力・即時判定に専念し、ディスクI/Oや重い計算は裏のワーカースレッドに非同期委譲する。

### なぜ counter++ はスレッドセーフではないのか？

一見すると1行の「counter++」ですが、アセンブリ言語（CPU機械語）レベルでは以下の3ステップに分解されます：

1. **レジスタへ読み込み**: MOV EAX, [counter]
2. **インクリメント**: ADD EAX, 1
3. **メモリへ書き戻し**: MOV [counter], EAX

もし2つのスレッド（Thread A と Thread B）が同時にこのコードを実行すると：
- Thread A が counter (値: 10) を読み込む
- その直後、OSのコンテキストスイッチが起き、Thread B も counter (値: 10) を読み込む
- Thread A が 11 を計算し、メモリに書き込む (counter = 11)
- Thread B も手元の 10 に 1 を足して 11 を書き込む (counter = 11)

本来 2 回インクリメントされたので **12** になるべき値が、**11** になってしまうのです！
これがゲーム内で起きると、所持金が消滅したり、敵の生存数が狂って無限ループに陥ります。

これを防ぐのが【ミューテックス（Mutual Exclusion：相互排他）】によるクリティカルセクションの保護です。

#ifndef LEGACY_MUTEX_QUEUE_HPP
#define LEGACY_MUTEX_QUEUE_HPP

#include <iostream>
#include <queue>

// POSIX環境 (Linux/macOS) または Windows に応じた低レイヤAPIの切り替え
#if defined(_WIN32)
#include <windows.h>
typedef CRITICAL_SECTION MutexHandle;
#define MUTEX_INIT(m)   InitializeCriticalSection(&(m))
#define MUTEX_LOCK(m)   EnterCriticalSection(&(m))
#define MUTEX_UNLOCK(m) LeaveCriticalSection(&(m))
#define MUTEX_DESTROY(m) DeleteCriticalSection(&(m))
#else
#include <pthread.h>
typedef pthread_mutex_t MutexHandle;
#define MUTEX_INIT(m)   pthread_mutex_init(&(m), NULL)
#define MUTEX_LOCK(m)   pthread_mutex_lock(&(m))
#define MUTEX_UNLOCK(m) pthread_mutex_unlock(&(m))
#define MUTEX_DESTROY(m) pthread_mutex_destroy(&(m))
#endif

// C++03時代の自作RAIIミューテックス
class Mutex {
private:
    MutexHandle handle_;
    Mutex(const Mutex&);
    Mutex& operator=(const Mutex&);
public:
    Mutex() { MUTEX_INIT(handle_); }
    ~Mutex() { MUTEX_DESTROY(handle_); }
    void lock() { MUTEX_LOCK(handle_); }
    void unlock() { MUTEX_UNLOCK(handle_); }
    MutexHandle* getHandle() { return &handle_; }
};

// スコープを抜けたら自動アンロックされるLockGuard（RAIIの真髄）
class ScopedLock {
private:
    Mutex& mutex_;
public:
    explicit ScopedLock(Mutex& m) : mutex_(m) { mutex_.lock(); }
    ~ScopedLock() { mutex_.unlock(); }
};

#endif

• アトミックではない単一文の罠: counter++ のような単純な操作でもCPUレベルでは複数命令に分解され、同期なしでは競合破壊される。
• RAIIによるScopedLockの徹底: 手動で lock()/unlock() を呼ぶと例外や早期returnで解除漏れ（永久デッドロック）を起こすため、コンストラクタでロック・デストラクタで解除するガードクラスを使う。

#include <iostream>
#include <queue>
#include <vector>
#include <string>

// 実行するタスクの基底インターフェース
class ITask {
public:
    virtual ~ITask() {}
    virtual void execute() = 0;
};

// サンプルタスク：アセットの非同期バックグラウンド読み込み
class LoadAssetTask : public ITask {
private:
    std::string filename_;
public:
    explicit LoadAssetTask(const std::string& filename) : filename_(filename) {}
    
    virtual void execute() {
        std::cout << "[WorkerThread] Loading asset: " << filename_ << std::endl;
    }
};

// スレッドセーフなタスクキュー（簡易概念実装）
class TaskQueue {
private:
    std::queue<ITask*> queue_;
public:
    void push(ITask* task) {
        queue_.push(task);
    }

    ITask* pop() {
        if (queue_.empty()) return NULL;
        ITask* task = queue_.front();
        queue_.pop();
        return task;
    }

    bool empty() const {
        return queue_.empty();
    }
};

int main() {
    TaskQueue taskQueue;

    taskQueue.push(new LoadAssetTask("textures/boss_dragon.png"));
    taskQueue.push(new LoadAssetTask("audio/stage3_bgm.ogg"));

    std::cout << "[MainThread] 60FPS描画を継続中... タスクは裏で処理されます。" << std::endl;

    while (!taskQueue.empty()) {
        ITask* task = taskQueue.pop();
        if (task) {
            task->execute();
            delete task;
        }
    }

    return 0;
}

• スレッド生成・破棄のコスト撲滅: スレッドはゲーム開始時にコア数分だけ生成して常駐待機させ、プールとして使い回すのが商用ゲームの鉄則。
• プロデューサー・コンシューマーパターン: メインスレッドがタスクを生産（Push）し、ワーカースレッドが消費（Pop）する構造により、完全な疎結合非同期処理を実現する。

• OS抽象化の歴史的必然性: Win32/pthreadのプラットフォーム依存の激しいスレッドAPIに苦しんだ歴史が、C++11での標準スレッドライブラリ策定へと繋がった。

• 1. CPUのクロック周波数が自動的に2倍になり、ゲームが高速化する
• 2. 描画ループがブロックされ、1フレーム16.6msを超過して画面が静止する（マイクロスタッター）
• 3. コンパイラがエラーを出して実行ファイルが削除される
• 4. ゲームの解像度が自動的にフルHDから4Kへ向上する

正解と解説を見る

正解：描画ループがブロックされ、1フレーム16.6msを超過して画面が静止する（マイクロスタッター）
メインスレッドがファイルI/Oで待たされると描画処理が実行できず、16.6ミリ秒のフレーム予算をオーバーして画面のカクつき（スタッター）が発生します。

• 1. メモリリーク（Memory Leak）
• 2. データ競合（Data Race / Race Condition）
• 3. バッファオーバーフロー（Buffer Overflow）
• 4. アライメントパディング（Alignment Padding）

正解と解説を見る

正解：データ競合（Data Race / Race Condition）
排他制御なしで複数スレッドが同一メモリへ同時にアクセスする状態をデータ競合（Data Race）と呼び、計算結果の狂いや不正ポインタ参照の原因になります。

• 1. スレッドの作成と破棄に伴う重いOSカーネルオーバーヘッドを回避し、高速にタスクを消化できるため
• 2. C++コードの行数が常に10行以下に短縮されるため
• 3. ミューテックスを使わなくてもデータ競合が絶対に起きなくなるため
• 4. メモリを全く消費しなくなるため

正解と解説を見る

正解：スレッドの作成と破棄に伴う重いOSカーネルオーバーヘッドを回避し、高速にタスクを消化できるため
スレッドの生成と破棄はスタック領域の割り当てやカーネル管理構造体の初期化を伴い非常に高コストです。常駐させたスレッドを使い回すプール設計が必須となります。

• 1. 関数の末尾に必ず手動で unlock() を書き、例外が起きたら諦める
• 2. RAII（Resource Acquisition Is Initialization）を利用し、コンストラクタでロックしデストラクタで自動アンロックするガードオブジェクトを使う
• 3. ミューテックスの代わりに goto 文で無限ループを作る
• 4. すべてのマルチスレッド処理をシングルスレッドに戻す

正解と解説を見る

正解：RAII（Resource Acquisition Is Initialization）を利用し、コンストラクタでロックしデストラクタで自動アンロックするガードオブジェクトを使う
RAIIを用いたScopedLock（モダンC++のstd::lock_guardなど）を使うことで、関数の途中でreturnしたり例外が発生してもスコープ離脱時に確実にアンロックされ、デッドロックを防げます。