ロックフリーのダイナミックメモリアロケータが（もっと）広く採用されていないのはなぜですか？
マルチスレッドプログラミング環境では、ヒープでのロックの競合がパフォーマンスのボトルネックになることがよくあります。
少なくとも理論的には、この問題の解決策は、スケーラブル/並列化[化]アロケーターを完全にロックフリーにすることです。ただし、有望な実験結果が含まれているいくつかの研究論文（[1] [2] [5]など）を除いて、完全にロックフリーのアロケータが実稼働環境に流れ落ちていないように思われます。反例で私が間違っていることを証明していただければ幸いです。では、ロックフリーアロケータのこの遅い（または存在しない）採用の実際的な理由は何ですか？ IntelのTBBのような、より広く使用されているスケーラブルアロケータは、きめ細かいロックを使用しますが、ロックフリーではないことに注意してください（[3]の315ページを参照）。
価値があるのは、CMUの学生プロジェクト/論文[4]もあり、最大64コアで「[Googleの] tcmallocよりも少し優れている」ロックフリーアロケーターを実装したと主張しています。その論文のもう1つの興味深い点は、「これらのテストのllallocは、Lockless Inc.のLockLessアロケーターであり、100％ロックフリーではありません（グローバルヒープの周りにロックがあります）」ということです。 jemallocとptmallocもそこでベンチマークされています。
参照：
[1] Michael、Maged M。 "スケーラブルなロックフリー動的メモリ割り当て。" ACM Sigplan Notices 39.6（2004）：35-46。 Michaelのアルゴリズムの独立した[再]実装を http://people.cs.vt.edu/~scschnei/streamflow/ で見つけました。
[2] Huang、Xiaohuang、他。 "Xmalloc：メニーコアマシン用のスケーラブルなロックフリー動的メモリアロケータ。" Computer and Information Technology（CIT）、2010 IEEE 10th International Conference on 。 IEEE、2010年。 MS論文としての論文の無料版 。
[3] Kukanov、Alexey、およびMichael J.Voss。 「インテルスレッディングビルディングブロックにおけるスケーラブルなマルチコアソフトウェアの基盤」 インテルテクノロジージャーナル11.4（2007）。
[4] Alex Podolsky、 Nah Lock：ロックフリーメモリアロケータ ;親ディレクトリのタイムスタンプとコース名の「S13」サフィックスに基づいて2013年に作成されたようです。
[5] Gidenstam、Anders、Marina Papatriantafilou、PhilippasTsigas。 "NBmalloc：ロックフリーの方法でメモリを割り当てます。" Algorithmica 58.2（2010）：304-338。 これに利用できるソースコード 。
脚注として、この質問に対する保留中の投票が4つあるのはわかりますが、 の投票はありません。なぜ、ハードウェアアクセラレータによるベクターグラフィックスがオフにならないのですか？ 。やや客観的な業績数値で答えられる可能性のある質問が、2〜3社の大企業の市場志向が主な要因である質問よりも意見が多い理由を誰かが説明できたら興味深いでしょう。
考えられる答えは次のとおりです。
IBMは特許を取得しています ロックフリーアロケーター...しかし、Linuxなどもサポートしているため、少なくとも実装を提供するインセンティブがある可能性があります。そしてXMallocの人たちも 彼らの特許を申請した 。しかし、NBmallocの特許（または特許出願）は[まだ]見つかりませんでした。
よりローカライズされた問題は、M。マイケルがその論文の直後にIBMでの出版を中止したように見えることです。彼がまだIBMに所属しているかどうかはわかりませんが、IBMが以前のWatson/Watson2アロケーターを使用してAIXに組み込んだように、IBMがアロケーターを製品化しようとしなかった理由は、彼を離れるかフォーカスを切り替えることである可能性があります。他のロックフリーアロケーターは、それらを製品に押し込む可能性のある大企業とは関係がないようです。
最後に、より一般的な理由は、コードの複雑さとパフォーマンスのメリットの相対的な比率です。 "非ブロッキングアルゴリズムがブロックしないことの証明" からの引用A. Gotsman et al。
ノンブロッキングデータ構造は、通常、ロックベースのデータ構造よりもはるかに複雑ですが、スレッド間の競合が大きい場合にパフォーマンスを向上させることができます。
したがって、コードの複雑さは、パフォーマンスの大幅な見返りによって正当化される必要があります。いくつかのロックフリーアロケーターペーパーはこれらを主張していますが...他のペーパーは反対のまたはウィッシュウォッシュの結果を考え出しました。特に、著者がMichaelのアルゴリズムを再実装した Streamflow paper は、ロックフリーではないアロケーターを使用してそれをしっかりと打ち負かしたと主張しています。 Podolskyのコースペーパー 比較的わずかな改善しか思いつきませんでした。したがって、ロックフリーのアロケータが追加の努力に値するのであれば、陪審員はまだ出ていないと思います。
ロックフリーアロケーター/デロケーターが使用されていないことをどのように知っていますか？たとえば、MacOS XおよびiOSでmallocを使用します。ロックフリーかどうか知っていますか？ （それらのドキュメントには、短いスレッドで同じスレッドでmallocとfreeを呼び出すのが非常に高速であると記載されていますが、これはあなたが心配しているケースです）。