各スレッドが 1 つのファイル専用である場合、各スレッドが作業中の 1 つのファイルに対して独自の MMF を作成することは理にかなっています。単一のスレッドによってのみ使用されるリソースは、スレッド内で割り当ておよび破棄する方が簡単です。
ただし、すべてのスレッドが同じファイルから読み取っている場合は、複数の MMF を作成したくありません。これは、消費されるメモリの量を増やし、一貫性の問題 (ファイルの同じセクションの複数のビュー) を作成するだけだからです。 )。
複数のスレッドが同じファイルを操作している場合は、MMF を一度作成し、MMF ポインタを複数のスレッドと共有する必要があります。
マルチスレッドの状況でのオンデマンドの割り当ては複雑になり、通常は保護されたリソースへのアクセスごとにロックが必要になります。ロックを要求すると、複数の独立したスレッドを実行することによるパフォーマンス上の利点がすぐに失われてしまいます。これらのスレッドがすべて整列して共有リソースへのアクセスを待機する必要がある場合です。
スレッドを構築/開始する前に共有リソースを割り当てることができる場合、スレッドが必要とするまでにリソースが常に存在するため、多くの場合、リソースへのアクセスをロックする必要はありません。
したがって、スレッドがスピンアップする前に MMF を割り当て、ロックなしですべてのスレッドで MMF ポインターを共有することを検討します。
これはまた、ファイルが厳密に読み取り専用であること、つまり複数のスレッドがファイルまたは MMF に書き戻さないことも前提としています。複数のスレッドが共通メモリ領域/MMF へのポインタを共有して、スレッドの同時実行の問題なしに読み取り専用アクセスを行うことができます。
従来のバッファリングされたファイル アクセスと比較して、MMF のパフォーマンスに関する想定に注意してください。ファイル データ全体が使用可能な RAM に問題なく収まる場合、MMF はバッファリングされたファイル I/O よりもランダム アクセス パターンに対してパフォーマンスが高くなる可能性があります。ファイル データが使用可能な RAM よりもはるかに大きい場合、バッファリングされたファイル I/O は、MMF を使用するよりもランダム アクセスのパフォーマンスが向上する可能性があります。なんで?MMF はメモリの使用に関して豚らしいからです。MMF は、4k ページ サイズのチャンクでのみデータをロードできます。バッファリングされたファイル I/O は、実際のデータ サイズのニーズとパターンに合わせてより細かく調整できます。アプリがファイル内の 100 の異なる場所から 512 バイトのデータを読み込む場合、512 * 100 = 50k のデータしか必要としない場合でも、MMF は 4k * 100 = 400k バイトのデータを読み込む必要があります。このデータアクセスパターン/ユースケースでは、
MMF の主な魅力は、多くの場合、生のパフォーマンスではなく、開発者の利便性です。通常、開発者にとっては、ブロック指向のファイル I/O サブシステムを作成して調整するよりも、MMF によってサポートされるポインターから読み取る方が便利です。その真実を認める限り、それは開発者にとって単純で便利なので、技術を使用することに何の問題もありません。