Re: nitpicky questions regarding mmap() and msync()

[Andi Kleen <ak@muc.de>]

In article <3B732DAE.CD117CBA@sympatico.ca>,
chris_friesen@sympatico.ca (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 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?

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.

> 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