私は自分に適したconcurrnetHashtableを作成していて、concurrentHashMapとは少し異なり、AtomicReferenceFieldUpdaterを使用してCASNext操作を行っています（通常はCASがサポートされていますが、これによってCASNextも実行できます）。通常、このconcurrentHashTableでは、ハッシュテーブルをロックするよりも優れたパフォーマンスが得られますが、うまくいかない場合もあります。
だから私は次の結論に達しました：
使用可能なプロセッサの数がハッシュテーブルで使用可能なバケットの数よりも多い場合、ロックの競合が発生する可能性が高くなります。したがって、この場合、concurrentHashTableはロックのアプローチよりもうまく機能します。もちろん、読み取りが多い場合（ジャーナルによると85- 90％の読み取り操作）、それならそれは使用に適しています..だから私に提案してください、私は正しい道を進んでいますか、そして物事を正しく仮定していますか？
時間があれば、このページのコードを参照してください
。このハッシュテーブルでは、要素がまだ存在しない場合に挿入を行っています...これが正しいロックフリーアプローチであるかどうかを教えてください。
2 に答える
1
直接的な回答ではありませんが、CHM の改善を検討している場合は、Cliff 博士によって書かれたものを参照してください。ここをクリックしてください。
それとは別に、何を解決しようとしているのかを知らずに助けるのは難しいです...
于 2013-02-01T20:56:02.763 に答える
0
同時ハッシュ マップでは、要素の追加、要素の削除、および再ハッシュという 3 つの主要な操作について考慮する必要があります。
削除と追加は、CaS だけで十分簡単です。
ただし、再ハッシュすると左右の競合が発生し、データが削除されたり、一部の操作で要素が表示されなかったり、無限ループが発生したりする可能性があります。これを正しく行うのは非常に難しく、テーブル全体で r/w ロックを使用する方がはるかに簡単です
于 2011-05-17T11:50:08.163 に答える