オブジェクトが C++ や Java などの言語で実際に低レベルの規模でロックされている場合、これは実行されますか? CPU/キャッシュやRAMとは関係ないと思います。私の最高の推測は、これがOSのどこかで発生するということですか? コンテキスト切り替えを実行する OS の同じ部分内にあるでしょうか?
オブジェクトのロック、メソッド署名 (Java) での同期などについて言及しています。
答えは、どの特定のロック機構に依存するのでしょうか?
オブジェクトが C++ や Java などの言語で実際に低レベルの規模でロックされている場合、これは実行されますか? CPU/キャッシュやRAMとは関係ないと思います。私の最高の推測は、これがOSのどこかで発生するということですか? コンテキスト切り替えを実行する OS の同じ部分内にあるでしょうか?
オブジェクトのロック、メソッド署名 (Java) での同期などについて言及しています。
答えは、どの特定のロック機構に依存するのでしょうか?
ロックには、同期プリミティブ (通常はミューテックス) が含まれます。素朴に言えば、ミューテックスは「ロックされている」または「ロック解除されている」ことを示すブール値のフラグにすぎませんが、詳細には悪魔がいます。ミューテックス値は、アトミックに読み取られ、比較され、設定される必要があります。その状態を壊さないでください。
しかし、それとは別に、mutex 変数の読み取りと書き込みの効果が正しい順序でプログラムに表示され、スレッドが失敗したためにクリティカル セクションに入るべきではないときに、誤ってクリティカル セクションに入るスレッドがないように、命令を適切に並べる必要があります。時間内にロックの更新を確認します。
メモリ アクセスの順序付けには 2 つの側面があります。コンパイラはいつ注意する必要があるかを知っているので、これを防ぐのは比較的簡単です。はるかに難しい現象は、CPU 自体が内部的に命令の順序を変更することを選択する可能性があり、ロックのためにミューテックス変数にアクセスしている場合は、そうしないようにする必要があります。これにはハードウェア サポートが必要です (たとえば、パイプライン フラッシュとバス ロックを引き起こす「ロック ビット」)。
最後に、複数の物理 CPU がある場合、各 CPU には独自のキャッシュがあり、実行中の命令がさらに進行する前に、状態の更新がすべての CPU キャッシュに伝達されることが重要になります。これにも、専用のハードウェア サポートが必要です。
ご覧のとおり、同期は (潜在的に) 高価なビジネスであり、並行処理の邪魔になります。ただし、これは、複数の独立したコンテキストが作業を実行する単一のメモリ ブロックを持つために支払う代償にすぎません。
C++ にはオブジェクト ロックの概念はありません。通常、OS 固有の関数の上に独自の関数を実装するか、ライブラリ (例: boost::scoped_lock
) によって提供される同期プリミティブを使用します。C++11 にアクセスできる場合は、boost と同様のインターフェイスを持つスレッド ライブラリによって提供されるロックを使用できます。
Java では、JVM によって同じことが行われます。
にはjava.lang.Object
モニターが組み込まれています。これは、synchronized キーワードをロックするために使用されるものです。JDK 6 では、よりきめ細かい選択肢を提供する同時実行パッケージが追加されました。
これには素晴らしい説明があります:
http://www.artima.com/insidejvm/ed2/threadsynch.html
私は長い間 C++ を書いていないので、その言語でそれを行う方法について話すことはできません。私が最後に書いたとき、それは言語でサポートされていませんでした。すべてサードパーティのライブラリまたはカスタム コードだったと思います。
私が知っているすべてのアーキテクチャは、アトミックなCompare And Swapを使用して同期プリミティブを実装しています。たとえば、Semiphore および ReentrantLock を実装するために一部の JDK バージョンで使用された AbstractQueuedSynchronizerを参照してください。
特定のロック メカニズム (通常はセマフォ) に依存しますが、実装に依存するため、確実ではありません。