[Boost-users] [interprocess] Fault recovery in managed mapped file

Subject: [Boost-users] [interprocess] Fault recovery in managed mapped file
From: Kevin Arunski (kevin.arunski_at_[hidden])
Date: 2010-11-17 09:14:35

I have found that managed mapped file can get stuck in a spinlock if the 
file is not closed and fully flushed to disk.  For example, if the power 
is pulled from computer while a segment is open and before the first 
page in the segment has been committed.  In this case it is common for a 
journaled filesystem to preserve the fact that the file was created, but 
it has lost the contents of the file and now the file appears to be 
zero'd out.  I have observed this behaviour on Linux systems running 
ext4, for example.

This loop is where we get stuck, in 
managed_open_or_create_impl::priv_open_or_create

while(value == InitializingSegment || value == UninitializedSegment){
     detail::thread_yield();
     value = detail::atomic_read32(patomic_word);
}

At this point I have opened the file in open_only mode.  *patomic_word 
is 0 (UninitializedSegment) at this point.  It appears this code is 
waiting for some other process or thread to initialize the segment, but 
in fact there is no such process doing so.

Some possible solutions:

If, at this point we have opened a file and not created it, why wait for 
an UnitializedSegment to change state?  If the segment is Unitialized 
here then simply throw an error.  Make it the caller's responsibility to 
ensure the segment is created/initialized before it opened in a 
read-only mode.

Perhaps, if you want to allow multiple processes to do open and create 
simultaneously without any additional synchronization mechanism, you 
could accomplish that by adding a count of open mappings into the shared 
segment.  If the reference count is 1 at this point, don't attempt this 
spinlock because the state of the file is never going to change.  In 
this case throw if the *patomic_word is != InitializedSegment.

-- 
KEVIN ARUNSKI