thanks for your reply. Am Thursday 10 December 2009 08:29:07 schrieb Ion Gaztañaga:
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.
or rename them entirely. there is a lot of confusion what flush/sync means. in POSIX, flush is flushing internal buffers to the operating system, and sync is synchronizing OS buffers with physical storage. in C++ iostreams, the function that flushes internal buffers is called pubsync(), while in boost iostreams it's called flush. and in interprocess flush() is synchronizing with physical storage (on linux) using msync(). that's not a highlight of c++ and boost in general, I think I'll have to use platform specific code for file and directory access, just to be able to call POSIX fsync() and fdatasync(). neither iostreams/boost iostreams nor boost.filesystem seem to provide that functionality.
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.
yes, but a flush like that has the goal to get some free memory. so it could e.g. refrain from flushing a page that was changed since the other thread started flush(), which is not what you want when your goal is to get the data to disk (if it contains the concurrent modifications or not doesn't matter). but I don't know either.
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.
I'm not using offset/size at all. the whole region is supposed to be flushed. I could track what pages got changed myself though, but I had the assumption that the OS already must have a list of dirty pages, so flush(offset,size) can't be faster than flush(). is that not the case?