私がロックフリープログラミングで集めたものから、正しく行うのは信じられないほど難しいです...そして私は同意します。いくつかの問題について考えるだけで頭が痛くなります。しかし、私が疑問に思うのは、なぜ高レベルのラッパーが広く使用されていないのですか（たとえば、ロックフリーキューなど）？たとえば、私が知る限り、ブーストにはロックフリーライブラリがありません。クリティカルセクションが負荷の大部分を占めるという事実を避けられないアプリケーションがたくさんあると思います。それで、理由は何ですか？それは...ですか...
だから私の質問は：なぜ「通常の」マルチスレッドプログラミングが「イン」であるのに、ロックフリープログラミングを深く使用する高レベルの抽象化があまり人気がないのですか？
編集：ブーストはロックフリーライブラリを取得しました:)
この分野に精通していて、使いやすいロックフリー ライブラリを実装できる人はほとんどいません。それらのいくつかのうち、無料で公開する作業はさらに少なく、ライブラリを使用可能にするために重要な追加作業を行う人はほとんどいません。たとえば、完全な API ドキュメントを公開するなどです。コードを含む zip ファイルをリリースするだけで、ほとんど役に立ちません。 . 次に、もちろん、使用したい言語で書かれ、使用しているプラットフォームでコンパイルされるライブラリを見つける必要があります。最後に、ライブラリの言葉を広めて、人々がその存在を知るようにする必要があります。
特許は、提供できるものを制限するという点で問題です。たとえば、私の知る限り、特許を取得していない単一リンク リストはありません。スキップリストのものもすべて特許を取得しています。
この分野のヒーローは Cliff Click です。彼はロックフリーのハッシュを思いつき、多かれ少なかれパブリック ドメインに置きました。
私のロックフリー ライブラリはここにあります。
もう 1 つは、Samy Bahra の Concurrency Kit です。
参考までに、Microsoftの.Netフレームワークは、.Net4.0でいくつかのロックフリークラスを取得しました。つまり、System.Collections.Concurrent名前空間のコンテナクラスは次のとおりです。
ConcurrentDictionary
ConcurrentQueue
ConcurrentStack
私はそれらの実装を調べましたが、それらは内部的には比較的厄介で複雑であるため、設計とテストにかなりの労力を費やしています（もちろん、スレッドの問題は高水準でテストするのが難しいことで有名です）。
libcds C++ ライブラリを見ることができます。これは、ロックフリー コンテナー (スタック、キュー、セット、およびマップ) と安全なメモリ再利用アルゴリズムのコレクションです。
C ++に関する私見（私は他の言語に精通していません）。新しい C++ 標準がリリースされたばかりで、コンパイラ開発者はその要件を実装する時間が必要です。現在、コンパイラの最適化ルールを大幅に変更する必要があるため、すべてのコンパイラが C++11 メモリ モデルを完全にサポートしているわけではありません。最近、Microsoft は、VC++ 11 Developer Preview でのロックフリー プログラミングのベースであるアトミック操作のサポートを発表しました。私たちにとって朗報です。私が知っているように、GCC は 4.8 (またはそれ以降) でそれをサポートする予定です。
第二の問題は特許です。多くの興味深いロックフリー コンテナー アルゴリズムは特許を取得しており、ベンダーのライブラリに含めることの障壁となっています。
第 3 に、ロックフリー コンテナーの主要部分はガベージ コレクション (安全なメモリ再利用) です。C++ には GC がありません (幸いなことに)。いくつかの GC アルゴリズム (ハザード ポインター、Pass-the-Buck、エポック ベースなど) がありますが、それらのほとんどは特許も取得しています。
第 4 に、ロックフリーの実装に適用されたメモリ フェンスの正確性を証明する手段が不十分です。今、私が知っているのはrelacy (http://www.1024cores.net/home/relacy-race-detector) だけです。
2 ～ 3 年後には、ロックフリーのコンテナーとアルゴリズムを備えた、本番環境に対応したマルチプラットフォーム C++ ライブラリが多数登場することになると思います。これらのライブラリは、ベンダーや愛好家によって開発されています。
しかし、私の意見では、私たちの未来はハードウェアトランザクション メモリ (HTM) です。今日、AMD、Sun (申し訳ありませんが、Oracle)、Intel (?) が HTM を調査しており、非常に興味深い結果が得られています。待とう。
やや人気のある「ロックフリー」フレームワークが少なくとも1つあります：Erlang。
大きな問題の 1 つは、過剰な数のメモリ バリアを使用しない限り、メモリ バリアが十分であることを確認するのが難しいことです。過剰な数のメモリ バリアを使用すると、ロックを使用した場合よりもパフォーマンスが低下する可能性があります。
ロックの最大の問題はパフォーマンスではなく、堅牢性です。スレッドがロックを保持している間にスレッドが道に迷った場合、システムは停止します。対照的に、ロックフリーのデータ構造にアクセスしているスレッドが待ち伏せされた場合、他のスレッドによるその使用には影響しません。状況によっては、パフォーマンスが劣っていても、ロックを使用するデータ構造よりもロックのないデータ構造が望ましい場合があります。、誤動作しているスレッドによってシステムがダウンするのを防ぐ必要があるためです (たとえば、プロセスを停止せずに StackOverflowException にヒットしたスレッドを強制終了する準備ができていたとしても、スレッドが大量のエラーを発生させないようにするにはどうすればよいでしょうか)。メソッドを呼び出してロック保護されたデータ構造にアクセスする前に、ロック保護されたメソッドがスタック オーバーフローにヒットするなど、そのスタックに何かを追加することはありますか?) ロックフリーのデータ構造を使用する場合、そのようなリスクは問題になりません。