nitpicky questions regarding mmap() and msync()

[Chris Friesen <chris_friesen@sympatico.ca>]

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