C# と VB.NET の質問掲示板

開発環境: Visual C++ 2010 / Windows 7

お世話になります。

ヘッダファイルで提供するクラステンプレートがありまして、このテンプレート内部からのみ使う
シングルトンクラスがあります。
(クラステンプレートの動作を高速化するためのプールです)

そして、このシングルトンクラスの生成をスレッドセーフにしたいのです。
提供するクラステンプレートがヘッダファイルのみで提供する形式なのでヘッダファイルのみで
記述したいと思っています。
そこで、提供するクラステンプレートと同じヘッダファイルに下記のように記述しました。

#頑張って考えたんですけど、自己流なので致命的な穴があるかもしれません。
#逆に既知のアイデアであって、それの下手な実装という可能性もあります。

class MyPool
{
    MyPool()
    {
        // いろいろ処理...
    }

    MyPool(const MyPool& rhs);                      // コピー禁止
    const MyPool& operator =(const MyPool& rhs);    // 代入禁止

public:

    static MyPool& GetInstance()
    {
        static MyPool* volatile pInstance;

        // 高速化のためにpInstanceが0であることを最初に確認
        if (!pInstance)
        {
            // 実体を動的に生成(スレッド競合があれば複数生成されるかもしれない)
            MyPool* pTmp = new MyPool();

            // そこでCASでアトミックにpInstanceに設定(設定できるのは最初の1スレッドだけ)
            if (InterlockedCompareExchangePointer(reinterpret_cast<volatile PVOID*>(&pInstance), pTmp, 0) != 0)
            {
                // 失敗したら既に先行スレッドがpInstanceに実体を設定した後ということ。
                // この実体は不要なので破棄します。
                delete pTmp;
            }
        }

        return *(static_cast<MyPool* const volatile &>(pInstance));
    }

    // 各種実装...

};

※このコードはMyPoolのコンストラクターが例外を送出しないことを前提としています。

とりあえず正常に動作しているように見えますが、何点か疑問点と問題があります。

1.GetInstance()内のpInstanceは初回に呼ばれたときに必ず 0 であることを期待しています。
  JIS X3014:2003 6.7の4項によると、『静的記憶期間を持つ全ての局所オブジェクトは、そのゼロ初期化を
  その他の全ての初期化が起きる前に実行する』とあるので、0 であるか比較するのは問題ないと考えています。
  また、ゼロ初期化がスレッド競合により複数回発生することもないと考えています。
  この解釈で大丈夫でしょうか?

2.実体を動的に確保しているので、デバッグ時に Visual Studio にメモリーリークがあると怒られてしまいます。
  出来れば動的な確保はしたくはないのですが、動的な確保なしにスレッドセーフにする方法を思いつけませんでした。
  プロセス終了時に解放されるはずなので問題はないと思いますが、解消できる方法があれば解消したいです。
  お知恵をお貸しいただけると嬉しいです。

3. volatile 修飾をつけるべきかどうか迷っています。
  最適化による弊害を防ぐためにポインター変数自体にvolatile 修飾を付けています。
  また、return 時にもポインター変数を一旦 const volatile な参照にキャストしています。
  Visual C++ 2010 では何もつけなくてもリリースビルドで正常に動作しますし、
  実際には不要ではないのかとも思っています。
  でも根拠がないので念のために修飾しています。
  ご意見を聞かせていただけると嬉しいです。

または、『こんな方法じゃ根本的ダメだ』等ありましたらヒントやキーワードだけでも結構ですので、
ご教示いただけると嬉しいです。

1/22 18:17 誤記の修正と例外についての制限事項を追記しました。

なんとか頑張って動的な確保なしにスレッドセーフに出来ました。

class MyPool
{
    MyPool()
    {
        value_ = 0;
        // いろいろ処理...
    }

    MyPool(const MyPool& rhs);                      // コピー禁止
    const MyPool& operator =(const MyPool& rhs);    // 代入禁止

    static const long INIT_NONE = 0;                // 未初期化。この値は0であること
    static const long INIT_INITIALIZING = 1;        // 初期化中(初回のGetInstanceImpl呼び出し中)
    static const long INIT_COMPLETED = 2;           // 初期化済み

    // シンプルなスレッドセーフではないシングルトンインスタンス取得メソッド本体
    static inline MyPool& GetInstanceImpl()
    {
        static MyPool instance;

        return instance;
    }

public:

    // ロックフリーでスレッドセーフなシングルトンインスタンス取得
    static MyPool& GetInstance()
    {
        static volatile long initStat;

        if (initStat != INIT_COMPLETED)
        {
            // CASでアトミックに『未処理状態なら初期化中状態にする』
            if (InterlockedCompareExchange(&initStat, INIT_INITIALIZING, INIT_NONE) == INIT_NONE)
            {
                // ここに入れるのは未処理状態 -> 初期化中状態に変更出来た1スレッドだけです。
                MyPool& instance = GetInstanceImpl();
                InterlockedExchange(&initStat, INIT_COMPLETED);
                return instance;
            }
            else
            {
                // ここに入るのは競合で負けて初期化中状態に出来なかったスレッドです。
                // 別スレッド(初期化中状態に出来た唯一のスレッド)が初期化を完了させるまで待ちます。
                while (initStat != INIT_COMPLETED) {}
            }
        }

        return GetInstanceImpl();
    }
};

※このコードはMyPoolのコンストラクターが例外を送出しないことを前提としています。

1.やはりゼロ初期化が競合しないことを前提にしていますが、大丈夫だと判断しました。
  根拠は JIS X3014:2003 8.5の6項に『静的記憶期間を持つオブジェクトは、プログラム開始時に、
  その他の全ての初期化に先行してゼロ初期化されなければならない』と明記されているからです。
  実際にはプログラムロード時にゼロ初期化されていると予想しています。

2.また、動的な確保を無くしたので Visual C++ 2010 に怒られなくなりました。
  GetInstanceImpl()はスレッドセーフではないシングルトンオブジェクト取得関数です。
  GetInstance()内でCASによってアトミックにステータスの比較と更新を行うことで、GetInstanceImpl()
  の初回の呼び出しで競合を起こすことを防いでいます。

これで一応の目的は果たせましたが、もう少し検討から解決としたいと思います。

#実行速度を計ったらシンプルなスレッドセーフではない実装より速いです。不思議??

VC++固有の処理で良いなら、__declspec(selectany)を使うことができます。

class MyPool
{
    static MyPool __instance;

    MyPool()
    {
        // いろいろ処理...
    }

    MyPool(const MyPool& rhs);
    const MyPool& operator =(const MyPool& rhs);

public:
    static MyPool& GetInstance()
    {
        return __instance;
    }
};

__declspec(selectany) MyPool MyPool::__instance;

C# の volatile にメモリバリア効果があるなら、

> ここでも過去にこんな議題が
> http://bbs.wankuma.com/index.cgi?mode=al2&namber=65737&KLOG=111

上記の No65894 で書いたサンプルでおかしな結果が起こることがないはず、
と思い、実験や調査を行ってみました。

もしかして、

> private static volatile bool[]  Locks = { false, false };

という書き方って、Locks 自体は volatile だけど、Locks[n] についてはそうではない、
とかなのかと思い、volatile bool[] の代わりに、 volatile bool の変数をふたつ
使うように変更してみたりもしましたが、VS 2012 の C# コンパイラでコンパイラ
しても相変わらずおかしな動きをするわけで。

そこで C# の言語仕様を当たってみました。
確かに順序の規定はありましたけど、完全なシーケンシャルバリアではないようです。

 - volatile フィールドの読み取り：それ以降のメモリ参照より先に行われることが保証されている。いわゆる acquire バリア。
 - volatile フィールドへの書き込み： それ以前のメモリ参照の後に行われることが保証されている。いわゆる release バリア。

といった規定のみ。つまり、volatile フィールドへの書き込み → 読み取り、とすると逆転の
可能性は残っていると考えるべきだと思いました。そうすれば辻褄があいますし。
例えば、

  volatile bool x;
  volatile bool y;

  ...

                 // ここより前のメモリ参照は (1) より前に行われることが保証されている
  x = true       // (1)
                 // ここの区間についての規定はない
  if (y)         // (2)
                 // ここより後のメモリ参照は (2)

とした場合、x への書き込みと y の評価が逆転。y を見てから x に代入
するといった動きをする可能性がある、と。

うーむ。C# でも volatile を付けたから無条件で安心、というわけにはいかないようです。