同じCPUで実行されている複数のスレッドのコンテキストで使用するCAS関数が必要です（すべてのスレッドがを介して選択したCPUに静的に接着されていると仮定しますSetThreadAffinityMask）。
InterlockedCompareExchangeLOCKCMPXCHGを生成します。LOCK部分には、キャッシュミス、バスロック、他のCPUとの競合の可能性などの副作用があります。これらはすべて素晴らしいですが、状況を考えると贅沢な過剰のように感じます。競合するスレッドは同じCPUで実行されるため、LOCKを削除できると思います。さらに、パフォーマンスが向上するはずだと思います。
だからこれが私の最初の質問です-私は正しく仮定していますか？
-
32ビットバージョンのインラインアセンブリでCMPXCHGを生成する方法を知っています。また、このSOスレッドによると、64ビットバージョンでも実行方法を知っていますが、関数呼び出しとしてです。
私が理解していないこと、そしてこれが私の2番目の質問ですが、それのインラインバージョンを生成する方法です。
-
ありがとう。
私自身の質問に答えるのではなく、ある種の回避策を説明するためです。
ブール変数のCASの場合、にフォールバックすることができます_bittestandset。これは、CMPXCHGよりも低速ですが、VS2010に固有の形式があります。
これは本当にコメントですが、スペースが少し限られています...
CMPXCHG私はあなたがアセンブリを使用せずにそれ自体で命令を得るだろうとは思わない* 。領域が非常に重要な場合は、インターロックされた組み込み関数を使用し、出力を分解し、オーバーライドプレフィックスを削除して、リンクします（インラインASMはMSVCでは最適ではないLOCKため、32ビットと64ビットの両方のバリアントでこれを行います。安全ではないものとして扱われ、余分な保護要素が挿入される原因になります。これは、外部バージョンを呼び出すよりも悪い場合があります。プラス面では、コードレイアウトがより均一になります）。
LOCKまた、最新のIntel CPUはキャッシュレベルのロックを実装しているため、両方のソリューションをプロファイルせずにプロファイルすることをお勧めします。これにより、ロックのパフォーマンスへの影響が大幅に軽減されます（ Intel開発者マニュアルの第8章では、バスロックの正確な効果）。
*「疑わしい」とは、明示的な組み込みとして存在しないことを意味します。コンパイラの強制トリックを使用することは非常に脆弱ですXCHG。-OP）。CMPXCHGXCHG (E)AX,(E)AX