nitpicky questions regarding mmap() and msync()
A couple questions about mmap()'d files.
1) If I have an mmap()'d file and I write to it and then I am hit with a SIGKILL before I have a chance to msync(), am I guaranteed that changes I've made to the information in the file will be available if I restart and try to mmap() the same file? The man page says only that there is no guarantee that changes are written back to disk if msync() is not called, but some informal testing seems to indicate that changes are in fact written out. Is this a timing issue or does the system guarantee this?
2) If I make changes to the contents of an mmap()'d file, am I guaranteed that the order I make the changes is the same order that they will be available to another process that has mmap()'d the same file? (Or can I be bit by optimization reordering? If this is the case, can I get around this by reading it as volatile and using the barrier() macro?)
The basic idea is that I have a state file stored in ramdisk in which I keep
track of some system state variables. This gets mmap()'d into memory. If my
process gets killed for whatever reason it can restart and read this file to check the state. One of the variables in this file is a flag that says whether or not its a valid file. If the file is invalid then more drastic recovery measures must be taken. I want to be sure that if I clear the flag before doing any multi-stage operations and then set it after I'm done, I can always guarantee that if that variable is set then the contents are valid. I would also like to avoid calling msync() after every change if I can avoid it.
Anyone know the definitive answers to these questions? I don't need posix standard behaviour, just what linux currently does (and is likely to do in the future, if it is different).
Thanks,
Chris
In article <[email protected]>,
Quoted 8 lines · [email protected] (Chris Friesen) writes:
A couple questions about mmap()'d files.
1) If I have an mmap()'d file and I write to it and then I am hit with a SIGKILL before I have a chance tomsync(), am I guaranteed that changes I've made to the information in the file will be available if I restart and try tommap()the same file? The man page says only that there is no guarantee that changes are written back to disk ifmsync()is not called, but some informal testing seems to indicate that changes are in fact written out. Is this a timing issue or does the system guarantee this?
The system does guarantee it. There is no special case for SIGKILL exit, it is just an ordinary exit and it does properly munmap all your mappings.
Quoted 5 lines
2) If I make changes to the contents of an mmap()'d file, am I guaranteed that the order I make the changes is the same order that they will be available to another process that has mmap()'d the same file? (Or can I be bit by optimization reordering? If this is the case, can I get around this by reading it as volatile and using the
barrie()macro?)
When two processes access the same mapping in Linux they always work on the same block of memory, so standard memory ordering rules apply. On a lot of architectures that means you need to use appropiate read and write barriers to avoid reordering on SMP systems.
[on some architectures like early mips chips there can be nasty issues with virtual cache aliases though, but that should not concern you here]
The memory can be flushed to disk and reread at any time, in this regard it is no different from any other anonymous memory, except that it is not written to swap but to your backing file.
The order in which the changes are flushed to disk is completely undefined.
-Andi