Stefan Strasser escribió:
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.
Thanks for the report. Maybe two flush version should be provided, flush() and async_flush(), each one with different guarantees.
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.
I really don't know. If underlying functions say nothing about it Interprocess can't say much more, but the OS should guarantee memory consistency even in the presence of a flush since the OS flushes the memory without an explicit flush call, just like it flushes its file buffers without user intervention.
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.
It seems strange. Maybe shared mapping is slower than private mapping, but I can only speculate.
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.
In theory , if the offset is not multiple of the page size you get memory overhead (and additional page flushes), because the OS requires aligned pages and mapped_region fixes that for you, but nothing more than that. If offset/size is page-aligned, it should have no impact. Best, Ion