マルチコアプロセッサ環境で古いプログラムがクラッシュする理由

タイムスタンプカウンタは本来、プロセッサの動作周波数という単位時間あたりの値の増加が一定の(おそらく、通常はシステム内で最も)高精度なカウンタです。しかし、プロセッサに省電力機能が実装されるようになると、必ずしもそうともいいきれない場面が生まれるようになってきました。

プロセッサの省電力機能は、ほとんどの場合、次の要素から成ります。

• 負荷状態や電源ソースに応じてプロセッサコアの動作周波数を変化させる
• プロセッサコアに供給する電圧を変化させる

ここでは後者のコア電圧の変化については無視して構いませんが、前者に挙げた動作周波数の変化は、TSCを使用するプログラムの動作に重大な影響を及ぼすことがあります。動作周波数が動的に変化する場合、TSC値の増加率には、大きく分けて次の2つのパターンが考えられます。

1. プロセッサコアの周波数の変化に伴って変化する
2. プロセッサコアの周波数の変化とは連動せず、常に一定の率で増加する

特にマルチコアプロセッサ環境では、どちらのパターンであっても、TSCの使用がプログラムのクラッシュの原因になる場合があります。

プロセッサの仕様やBIOSの実装にもよりますが、理論上は、マルチコアプロセッサの省電力機能は、内蔵する複数のコアの動作周波数を個別に制御する可能性があります*2。同じように、物理的に複数のCPUソケットを持つマルチプロセッサ環境でも、理論上はCPUソケットごとの負荷状態によって動作周波数が異なっている可能性があります。

したがって、たとえばひと口に3GHzのマルチコアプロセッサといっても、内蔵されている個別のコアのある時点での動作速度は異なっているかもしれません。このことから、TSCのカウントアップ率が動作周波数によって変化するタイプのプロセッサであれば、プロセッサのリセット時から累積されてきたTSC値は、ある時間において、コアごとに異なっていてもおかしくないということが理解できると思います。

まず結論からいってしまえば、プログラム側でプロセスまたはスレッドとプロセッサコア*3との親和性を指定しない場合、マルチコア(あるいはマルチプロセッサ)環境でプログラムコードの一部がどのプロセッサコア上で実行されるかは予測できません。

なぜなら、プロセッサコアとの親和性を指定されていないコードをどのプロセッサコアで実行するかを決めるのはOS(とプロセッサ)の役目であり、OSはコアの負荷状態やプロセッサ上のキャッシュの状態に応じて、システム全体のパフォーマンスを損なわない選択をすべきだからです*4。

しかし、マルチ(コア)プロセッサの性能を生かしてシステム全体のパフォーマンスを向上させるためのこのOSの配慮が、TSCを使用する古いソフトウェアに不幸をもたらします。詳細は後述することにして、まずはプロセッサコアとの親和性を指定されていないプログラムコードの一部がどのコアで実行されるかを予測できないという事実を、実際のプログラムの一例を挙げて見てみましょう。

// laid.cpp
#include <iostream>
#include <intrin.h>

int checkLocalApicId()
{
    int info[4];
    __cpuid(info, 1);

    return (info[1] >> 24) & 0xff;
}

int main()
{
    for(int i=0, apid_i=checkLocalApicId(), apid=apid_i; apid==apid_i && i<1000; ++i)
    {
        apid = checkLocalApicId();
        std::cout << apid << std::endl;
    }

    return 0;
}

Intel Pentium4以降のプロセッサでは、EAXレジスタに1をセットしてCPUID命令を実行すると、EBXレジスタにロードされた値のビット31〜24がプロセッサコアのローカルAPICの物理IDとなります[2] [3](コードではMicrosoft Visual Studioに付属のintrin.hヘッダに含まれている__cpuid関数を使用しています)。上記のコードは、最初に取得したLocal APIC IDと異なるLocal APIC IDが得られるかどうかを1000回試行し、得られればそこで終了します。

実行するたびに結果は異なりますが、AMD Phenom II X4(4コアのマルチコアプロセッサ)上で実行したある1回の結果は次のようになりました。

2
2
1

この環境ではLocal APIC IDは0から3のいずれかの数字になりますが、CPUID命令を単純なループで繰り返し実行するだけでも、どのコアで実行されるかは予想できないということがわかると思います*5。

マルチコアプロセッサでのタイムスタンプカウンタの使用

ハードウェアがサポートしていれば、TSCの代替としてQueryPerformanceCounter関数を使えるかもしれませんが、MSDNライブラリの解説によれば、BIOSやHALのバグによって異なったプロセッサを呼び出した場合に異なった結果が得られる可能性があると書かれているため、結局のところあまり解決にはなっていません。

実際には、QueryPerformanceCouter関数は、次に述べるSetThreadAffinityMask関数などと併用することになります。

最も確実な解決方法は、SetProcessAffinityMask関数またはSetThreadAffinityMask関数を使用して、TSCの値を読み出すプロセッサコアを限定してしまうことです。同一のプロセッサコアであれば、ある時点で読み出したTSC値よりもその後に読み出したTSC値が小さくなることはない*8ので、少なくとも後から読み出した値と最初に読み出した値の差分が負になることはありません。

上でコードの実行されるプロセッサコアを確かめたコードに少し手を加えて、常に同一のプロセッサコアでコードが実行されることを確かめてみましょう。

// laid2.cpp
#include <iostream>
#include <intrin.h>
#include <Windows.h>

int checkLocalApicId()
{
    int info[4];
    __cpuid(info, 1);

    return (info[1] >> 24) & 0xff;
}

int main()
{
    SetProcessAffinityMask(GetCurrentProcess(), 1);

    for(int i=0, apid_i=checkLocalApicId(), apid=apid_i; apid==apid_i && i<1000; ++i)
    {
        apid = checkLocalApicId();
        std::cout << apid << std::endl;
    }

    return 0;
}

変更した部分を強調しています。SetProcessAffinityMask関数の2個目の引数には、32ビット(DWORD値)で表現されるプロセッサとの親和性(アフィニティマスク)を渡します。このアフィニティマスクは各ビットがプロセッサコアに対応し、セットされているビットに対応付けられたプロセッサコアのみでそのプロセスが実行されます。例では1を渡しているので、コードはシステムの最初のプロセッサコアでしか実行されません。

実行結果をここに示しても良いのですが、0という1文字だけの行が1000行続く結果を見て興味深いと思ってくれる人がいるとは思えないのでやめておきます。

アフィニティマスクを指定する手法の欠点

プロセッサをタイムスタンプカウンタが一定であることが保証されているものへ変更する

プロセッサの省電力機能の無効化

プロセッサベンダから提供されるドライバの使用

タスクマネージャを使用する方法

互換モードを使用する方法