mmap，msync(MS_ASYNC)和munmap [英] mmap, msync(MS_ASYNC) and munmap

问题描述

如果我在内存映射区域上使用MS_ASYNC调用msync，则同步过程将被异步处理.

If I call msync with MS_ASYNC on a memory mapped region, the sync process will be handled asynchronously.

但是，如果我立即在该区域上调用munmap，我是否可以假设msync将被安全执行?还是我必须在munmap之前致电msync?

However, if I call munmap immediately on that region, can I assume that the msync will be carried out safely? Or will I have to call msync before munmap?

推荐答案

简短的答案是肯定的-即使您从不调用msync.来自man 2 mmap:

The short answer is yes -- the changes to the contents will eventually (and safely) make their way to the file, even if you never call msync. From man 2 mmap:

MAP_SHARED
          Share this mapping.  Updates to the mapping are visible to other
          processes that map this file, and are carried through to the
          underlying file.  (To precisely control when updates are carried
          through to the underlying file requires the use of msync(2).)

也许更重要的是，man 2 msync有这个注释:

Perhaps more to the point, man 2 msync has this note:

从Linux 2.6.19开始，MS_ASYNC实际上是禁止操作的，因为内核可以正确跟踪脏页并将其刷新到必要的存储空间.

Since Linux 2.6.19, MS_ASYNC is in fact a no-op, since the kernel properly tracks dirty pages and flushes them to storage as necessary.

请记住:mmap直接将文件系统缓存的页面暴露给用户空间，并且像其他任何缓存系统一样，更改将在将来的某个时刻传播到后备存储.即使您的程序崩溃，对页面所做的更改最终仍会传播. msync的使用是为了保护您免受断电之类的损害.

Remember: mmap is directly exposing pages of the filesystem cache to userspace and, just like any other caching system, changes will be propagated to the backing storage at some point in the future. Even if your program crashes, the changes you made to the pages will eventually get propagated. The use of msync is to protect you from things like power loss.

这篇关于mmap，msync(MS_ASYNC)和munmap的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！