Jaký je rozdíl mezi zápisem do souboru a namapovanou pamětí?

1. Jedním z důvodů může být to, že máte (starší) kód, který je nastaven tak, aby zapisoval do datové vyrovnávací paměti, a tato vyrovnávací paměť je pak na konci zapsána do souboru najednou. V tomto případě pomocí mmap uloží alespoň jednu kopii dat, protože OS může přímo zapisovat vyrovnávací paměť na disk. Dokud jde pouze o zápis souborů, neumím si (zatím) představit žádné jiné důvody, proč byste chtěli použít mmap .

2. Ne, zde bych řekl, že ochrana není relevantní.

3. Může uložit jednu nebo dvě kopie dat např. vyrovnávací paměť aplikace do vyrovnávací paměti libc do vyrovnávací paměti OS, viz bod 1. To může způsobit rozdíl ve výkonu při zápisu velkého množství dat.

4. Ne. Pokud vím, OS si může data zapisovat, kdykoli se mu zlíbí, pokud byla data zapsána na disk po volání msync nebo munmap v této oblasti paměti. (A pro většinu souborů pravděpodobně většinu času nezapíše nic mezi tím, z důvodů výkonu:zápis celého bloku na disk, protože se změnil jeden bajt, je poměrně drahý, zejména pokud se dá očekávat že v blízké budoucnosti dojde k mnoha dalším úpravám bloku.)

Soubor mapovaný do paměti je ve skutečnosti částečně nebo zcela mapován v paměti (RAM), zatímco soubor, do kterého zapisujete, by byl zapsán do paměti a poté vyprázdněn na disk. Soubor mapovaný do paměti je odebrán z disku a umístěn do paměti explicitně pro čtení a/nebo zápis. Zůstane tam, dokud jej nezmapujete.

Přístup k disku je pomalejší, takže když zapíšete do souboru, bude vyprázdněn na disk a již nebude uložen v paměti RAM, což znamená, že až budete příště soubor potřebovat, můžete jej získat z disku ( pomalé), zatímco v souborech mapovaných v paměti víte, že soubor je v paměti RAM a můžete k němu mít rychlejší přístup, než když je na disku.

Soubory mapované do paměti se také často používají jako mechanismus IPC, takže dva nebo více procesů mohou snadno sdílet stejný soubor a číst/zapisovat do něj. (pomocí nezbytných synchronizačních mechanismů)

Když potřebujete často číst soubor a tento soubor je poměrně velký, může být výhodné jej namapovat do paměti, abyste k němu měli rychlejší přístup a museli jej pokaždé otevřít a získat z disku.

UPRAVIT:

To záleží na vašich potřebách, když máte soubor, ke kterému bude nutné přistupovat velmi často různými vlákny, pak si nejsem jistý, že mapování paměti souboru bude nutně dobrý nápad, z toho pohledu, že budete muset synchronizovat přístup k tomuto mmap'ed souboru, pokud si přejete, aby do něj zapisoval, na stejná místa z různých vláken. Pokud se to stane velmi často, může to být místo pro spor o zdroje.

Pouhé čtení ze souboru, pak to může být dobré řešení, protože ve skutečnosti nepotřebujete synchronizovat přístup, pokud jste pouze čtení z něj z více vláken. Ve chvíli, kdy začnete psát, musíte používat synchronizační mechanismy.

Navrhuji, abyste každému vláknu zajistili vlastní přístup k souboru místním vláknem, pokud musíte do souboru zapisovat, stejně jako to děláte s jakýmkoli jiným souborem. Tímto způsobem snižuje potřebu synchronizace vláken a pravděpodobnost výskytu chyb, které je těžké najít a odladit.

1) Špatně jste pochopili systémové volání write(2). write() nezapisuje, pouze zkopíruje obsah vyrovnávací paměti do řetězce vyrovnávací paměti operačního systému a označí jej jako nečistý. Jedno z vláken operačního systému (bdflush IIRC) vezme tyto vyrovnávací paměti, zapíše je na disk a pohraje si s některými příznaky. později. S mmap máte přímý přístup k vyrovnávací paměti operačního systému (ale pokud změníte její obsah, bude také označen jako nečistý)

2) Nejde o ochranu, jde o nastavení příznaků v položkách stránkovací tabulky.

3) vyhnete se dvojitému ukládání do vyrovnávací paměti. Také můžete soubor adresovat pomocí znaků místo bloků, což je někdy praktičtější

4) Jsou to systémové vyrovnávací paměti (zapojené do vašeho adresního prostoru), které používáte. Systém může nebo nemusí mít zapsané části na disk.

5) Pokud vlákna patří ke stejnému procesu a sdílejí stránkovací tabulky a adresní prostor, ano.