Boost logo

Boost Users :

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.



Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at