8

Synchronization and Multiprocessor Issuesの記事を読みましたが、InterlockedCompareExchange と InterlockedExchange について質問があります。質問は、実際には記事の最後の例に関するものです。それらには2つの変数がiValueありfValueHasBeenComputed、次CacheComputedValue()を使用してそれぞれを変更しますInterlockedExchange。

InterlockedExchange ((LONG*)&iValue, (LONG)ComputeValue());  // don't understand
InterlockedExchange ((LONG*)&fValueHasBeenComputed, TRUE); // understand

InterlockedExchange改造に使えるのは分かるiValueけど、やるだけでいいの？ 

iValue = ComputeValue();

では、実際にInterlockedExchangeiValue を設定するために使用する必要がありますか? または、他のスレッドは iValue を正しく認識しiValue = ComputeValue();ます。iValue の後にあるため、他のスレッドは iValue を正しく認識しInterlockedExchangeます。

A Principle-Based Sequential Memory Model for Microsoft Native Code Platformsという論文もあります。ほぼ同じコードの 3.1.1 の例があります。おすすめの一つMake y interlocked。注意 - と の両方yではありませんx。

更新
質問を明確にするためだけに。問題は、私が矛盾していることです。「同期とマルチプロセッサの問題」の例では、2 つのInterlockedExchange. それどころか、例 3.1.1「基本的な Reodering」 (最初の例と非常に似ていると思います) では、Herb Sutter がこの推奨事項を示しています。

「y をインターロックする: y がインターロックされている場合、y は原子的に更新可能であるため競合はなく、a -> b -> d であるため x には競合がありません。」

. このドラフトでは、ハーブは 2 つの連動変数を使用しません (私が正しければ、彼はInterlockedExchangeのみに使用することを意味しますy)。

4

4 に答える 4

1

iValueのアドレスがアトミックアクセスを保証するアドレスにアラインされていない場合、部分的な読み取り/書き込みを防ぐためにこれを行いました。この問題は、2 つ以上の物理スレッドが同時に値を書き込もうとした場合、または 1 つのスレッドが読み取りを行い、1 つが同時に書き込みを試みた場合に発生します。

2 つ目のポイントとして、ストアは常にグローバルに表示されるわけではなく、フェンスまたはバス ロックによってシリアル化された場合にのみ表示されることに注意してください。

于 2011-10-07T11:10:50.913 に答える
0

この議論には、「潜在記憶の障壁」という質問に対する答えがあると思います。

質問：T1とT2でInterlockedExchange（暗黙のフルフェンス）を呼び出すと、T2はフェンスの前にT1によって行われた書き込みを「見る」ことができますか？（A、B、C変数）、これらの変数はFooやBarと同じキャッシュライン上にあるプランスではありませんか？

回答：はい-InterlockedExchangeによって生成された完全なフェンスは、InterlockedExchange呼び出しに暗黙的に含まれるフェンスを超えて、A、B、およびCへの書き込みが並べ替えられないことを保証します。これがメモリバリアセマンティクスのポイントです。それらは同じキャッシュライン上にある必要はありません。

メモリバリア：ソフトウェアハッカーのハードウェアビューとXbox360およびMicrosoftWindowsのロックレスプログラミングの考慮事項も興味深いものです。

于 2011-10-19T10:24:03.043 に答える
0

でアトミック操作を取得するだけですInterlockedExchange。なぜそれが必要なのですか？原因InterlockedExchangeは2つのことを行います。

  1. 変数の値を置き換えます
  2. 古い値を返します

2 つの操作で同じことを行うと (つまり、最初に値を確認してから置換する)、これら 2 つの間に (別のスレッドで) 他の命令が発生すると、失敗する可能性があります。

また、この値でのデータ競合も防ぎます。ここでは、LONG での読み取り/書き込みがアトミックではない理由について、適切な説明が得られます。

于 2011-10-07T11:10:16.340 に答える
0

あなたが観察した矛盾には、2 つのもっともらしい解決策があります。

1 つは、2 番目の文書がその特定の点で単純に間違っているということです。結局のところ、それはドラフトです。あなたが参照している例では、プログラマーは書き込みがアトミックであることに依存できないと具体的に述べていることに注意してください。つまり、両方の書き込みが実際に連動している必要があります。

もう 1 つは、その特定の例では追加のインターロックが実際には必要ない場合があることです。これは、変数の 1 ビットのみが変更されるという非常に特殊なケースであるためです。ただ、開発中の仕様書では前提として言及されていないようで、意図的なものではないかと思います。

于 2011-10-08T22:44:08.540 に答える