2

アプリケーションが Windows をターゲットにしており、その一部で既にコンカレンシー ランタイムを使用している場合。ConcRT タスク以外のconcurrency:critical_section標準ライブラリ実装 ( ) よりもConcRT 同期構造 ( ) を使用する利点/欠点はありますか? std::mutex(例: WinAPI 非同期コールバックの同期、または dll のエクスポートされた関数間のデータ アクセスの管理)

MSDN のドキュメントで<mutex>は、ConcRT に基づいていると記載されていますが、内部でミューテックスが critical_section を使用しているため、すべての状況で速度が低下し、移植性にのみ利点があるということですか?
または、逆に、critical_section は ConcRT スケジューラで使用するために特別に設計されており、OS スレッドで使用すると非常にやり過ぎですか?

PS この質問は、コンカレンシー ランタイムのすべての同期構造 (critical_section、reader_writer_lock & event) に関するものです。また、WinAPI の、、およびその他
を除外し、それらが最速かつ最軽量のソリューションであると想定しました (ただし、最も美しいわけではありません)。CRITICAL_SECTIONMUTEXSRW

4

1 に答える 1

1

std:mutex を concurrency::critical_section に変更する必要がありました。これは、実際には動作が異なるためです。mutex がブロックされると単純にブロックされ、critical_section がブロックされると ConcRT は新しいスレッドを開始/再利用します (利用可能な場合)。私の場合、切り替えを行う前に、この違いにより多くの並列性が失われました。

http://msdn.microsoft.com/en-us/library/ff601929.aspxの「可能な場合は協調同期構造を使用する」を参照してください。

于 2013-08-16T07:02:03.833 に答える