[Boost-users] [interprocess] mapped_region::flush()

Subject: [Boost-users] [interprocess] mapped_region::flush()
From: Stefan Strasser (strasser_at_[hidden])
Date: 2009-12-09 14:43:35

Hi,

I have a few questions regarding mapped_region.

1. first of all, is mapped_region::flush() safe to use?

on linux it is implemented as msync(MS_SYNC) which seems fine, but on windows 
it uses FlushViewOfFile alone, which IIUC does not flush the changes to disk.

MSDN:
"The FlushViewOfFile function [...] does not wait to return until the changes 
are flushed from the underlying hardware disk cache and physically written to 
disk. To flush all the dirty pages plus the metadata for the file and ensure 
that they are physically written to disk, call FlushViewOfFile and then call 
the FlushFileBuffers function."

I'm not sure if they really mean "hardware disk cache", since no sync or flush 
function can entirely make sure of that. but FlushFileBuffers is documented 
to flush operating system buffers. and the quote above says a call to 
FlushFileBuffers is necessary.

2.
can the mapped memory be accessed while another thread is calling flush()?
does that affect the flushing? it is still required that all data that was 
written to the mapped region at the point of the flush() call is written to 
disk when it returns. Interprocess' documentation doesn't say anything about 
that and I can't seem to find any information about that on the underlying 
functions mmap/FlushViewOfFile either.

and 3, not entirely boost related:
I get some strange performance results using mapped_region::flush() on linux 
(not tested on windows so far). I already reduced the flush() calls to a 
minimum but I still get better performance in many cases using my own filebuf 
implementation that performs paging without hardware support, using a 
std::filebuf.
using std::filebuf shouldn't be faster than hardware file mapping.
when I call flush() relatively frequently that in itself drives performance 
down, but when I call it less frequently it blocks for noticeable amounts of 
time. (thus, question 2)
do the offset/size arguments to mapped_region::flush() affect performance?
I could track what pages are changed, but I was under the assumption the OS 
already does that.

Thanks