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

Subject: Re: [Boost-users] [interprocess] mapped_region::flush()
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2009-12-10 02:29:07

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