Win32 プラットフォームでアトミック操作を提供するライブラリの代わりに、インターロックされた winapi 関数を使用することの利点と欠点は何ですか?
携帯性は問題ありません。
Win32 プラットフォームでアトミック操作を提供するライブラリの代わりに、インターロックされた winapi 関数を使用することの利点と欠点は何ですか?
携帯性は問題ありません。
移植性が問題にならない場合は、基本的に、これを正しく行うために誰を信頼するかを決める必要があります。ライブラリは通常、移植性を提供するように設計されています。それ以外の場合は、15年以上にわたって戦いが強化されてきたOS提供の実装と競争するのに苦労しています。
このスレッドをチェックして、明らかな実装が実際には最良ではない方法の例を確認してください。
インターロックされた winapi 関数は、ロックされた操作に対する CPU サポートがない場合でも、古いプロセッサで動作します。386 とおそらく 486 ですが、Win9x と古い NT をまだサポートしていない限り、今日では実際には問題になりません。
問題の特定のアトミック ライブラリに依存する可能性があります。
特定のバックエンドを備えた優れたライブラリは、x86ロック命令を発行してその作業を行うためのいくつかの ASM 命令の同じ実装になる可能性があります。そして、ライブラリ自体が移植可能であると仮定すると、その後、コードを移植可能にします。
単純なアトミック実装は、ミューテックスを使用して通常の変数を保護するなど、より重いことを行う可能性があります。私はそれができることを知りません - 議論の要点を作っているだけです。
そのため、記載されている非移植性の要件を考えると、Win32 関数を使用しても問題ありません。別の方法として、アトミック バージョンを使用することもできますが、実際の実装を検討することをお勧めします。