Re: [Boost-users] [interprocesss] managed_mapped_file mutex question

Subject: Re: [Boost-users] [interprocesss] managed_mapped_file mutex question
From: Andy Wiese (andyw_at_[hidden])
Date: 2010-03-19 01:00:16

On Mar 18, 2010, at 8:43 PM, Ion Gaztañaga wrote:

> El 18/03/2010 16:55, Andy Wiese escribió:
>> Many processes will both read and write this index map. Do the
>> interprocess:: containers provide the needed synchronization, or do I
>> need other synchronization mechanisms?
>
> You need to provide them. Interprocess memory allocation (via  
> construct<>, or allocate(), or through allocators) is thread-safe,  
> just like ::new is thread safe for inter-thread programming. But  
> similarly to inter-thread programming interprocess::map offers the  
> same guarantees as std::map, because interprocess containers are  
> standard-conforming containers: you must provide your own  
> synchronization if you use the same object by two processes-theads  
> and one is inserting or erasing elements.
>
> Best,
>
> Ion
>

Thank you. That makes perfect sense and is now proven by my test  
program.

I have a couple of questions about crash protection, which is very  
important in this case:
1. I am using only file_lock, because it is guaranteed to be released  
if the process crashes (if I understand correctly). However, file_lock  
has its limitations. If I use a named_recursive_mutex instead, is  
there any way to clear the mutex if the process terminates while  
holding the mutex?
2. If the mapped file gets corrupted, e.g. if a process gets killed  
while writing the file, I need to be able to detect that case and  
rebuild the file, but the file is certain death to any process that  
touches it, so validating it seems messy. Any suggestions how to  
detect a bad file?

Andy