理由の 1 つは、データ バッファーに書き込むように設定された (レガシ) コードがあり、このバッファーが最後に一度にファイルに書き込まれることです。この場合 mmap を使用 OSはバッファをディスクに直接書き込むことができるため、少なくとも1つのデータのコピーを保存します。ファイルの書き込みのみに関するものである限り、 mmap .
いいえ、保護はここでは関係ありません。
たとえば、データの1つまたは2つのコピーを保存する場合があります。 app バッファーから libc バッファー、OS バッファーへ。ポイント 1 を参照してください。これにより、大量のデータを書き込むときにパフォーマンスに違いが生じる可能性があります。
いいえ。私の知る限り、msync の呼び出し後にデータがディスクに書き込まれている限り、OS は好きなときにいつでも自由にデータを書き込むことができます。 または munmap そのメモリ領域に。近い将来、ブロックに対してさらに多くの変更が行われる予定です。)
メモリ マップ ファイルは実際には部分的または全体的にメモリ (RAM) にマップされますが、書き込むファイルはメモリに書き込まれてからディスクにフラッシュされます。メモリ マップ ファイルはディスクから取得され、読み取りおよび/または書き込みのために明示的にメモリに配置されます。マップを解除するまでそこにとどまります。
ディスクへのアクセスは遅くなるため、ファイルに書き込みを行うと、ファイルはディスクにフラッシュされ、RAM には存在しなくなります。つまり、次にファイルが必要になったときに、ディスクからファイルを取得する可能性があります (一方、メモリ マップ ファイルでは、ファイルが RAM にあることがわかっているため、ディスク上にあるときよりも高速にアクセスできます。
また、mememory マップ ファイルは IPC メカニズムとしてよく使用されるため、2 つ以上のプロセスが同じファイルを簡単に共有し、読み書きすることができます。 (必要な同期メカニズムを使用)
ファイルを頻繁に読み取る必要があり、このファイルが非常に大きい場合は、そのファイルをメモリにマップして高速にアクセスできるようにすると、毎回ファイルを開いてディスクから取得する必要がなくなります。
編集:
場合による 必要に応じて、異なるスレッドから非常に頻繁にアクセスする必要があるファイルがある場合、同期する必要があるという観点から、ファイルのメモリマッピングが必ずしも良い考えになるかどうかはわかりません異なるスレッドから同じ場所に書き込みたい場合は、この mmap されたファイルにアクセスします。これが頻繁に発生する場合は、リソースの競合が発生する可能性があります。
ファイルから読み取るだけなら、これは良い解決策かもしれません。なぜなら、アクセスを同期する必要がないからです。 複数のスレッドから読み取る。書き始めた瞬間にそうしなければならない 同期メカニズムを使用します。
ファイルに書き込む必要がある場合は、他のファイルと同じように、各スレッドにスレッドローカルな方法で独自のファイルアクセスを実行させることをお勧めします。このようにして、スレッド同期の必要性と、見つけてデバッグするのが難しいバグの可能性を減らします。
1) write(2) システムコールを誤解しています。 write() は書き込みを行いません。バッファの内容を OS バッファ チェーンにコピーし、ダーティとしてマークするだけです。 OS スレッドの 1 つ (bdflush IIRC) がこれらのバッファーを取得し、ディスクに書き込み、いくつかのフラグをいじります。 mmap を使用すると、OS バッファに直接アクセスできます (ただし、その内容を変更すると、ダーティとマークされます)
2) これは保護に関するものではなく、ページテーブル エントリにフラグを設定するためのものです。
3) ダブルバッファリングを回避します。また、ブロックではなく文字でファイルをアドレス指定することもできます。これはより実用的な場合もあります
4) これは、使用しているシステム バッファ (アドレス空間にフックされている) です。システムはその一部をディスクに書き込んでいる場合もあれば、そうでない場合もあります。
5) スレッドが同じプロセスに属し、ページテーブルとアドレス空間を共有している場合、はい。