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 13:33:20

On Mar 19, 2010, at 11:31 AM, Brett Gmoser wrote:

>
>> 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
>>
> Yeah, I think our problems are pretty similar. Unfortunately I  
> haven't gotten much input on it - I posted it before, and didn't get  
> and responses. I posted it again because I had seen that Ion was  
> active here recently.
>
> The only input I can offer you (I'm not much of an expert with the  
> Interprocess library) is that I believe that named_recursive_mutex  
> also has filesystem persistence.  It creates files in /tmp/ 
> boost_interprocess/XXXXX/name, where XXXXX seems to be a hash of the  
> machine's boot time.
>

Referencing Ion's last reply. I think I will stick with file_lock for  
now, which I am able to wrap my own classes around to make an adequate  
recursive mutex. I have been using the flock style utilities on os-x  
and freebsd for some time now, and it seems to be dependable.

I find myself wondering what are the conditions in which I would ever  
be comfortable using another lock type. I suppose if I had strict  
control and confidence in all processes, which is certainly not my  
current case.

As for data corruption, I was also thinking along the lines of Ion's  
suggestion:
> This depends on your application, and it's similar to when a thread  
> corrupts a data structure used by another thread. You could  
> serialize them and mark the start and end of a modification, so that  
> a thread could check if a previous process/thread has finished the  
> modification. This obviously, requires collaborative processes.

Accepting the constraint that I am trying to protect only against a  
file writer leaving a corrupt file by terminating abruptly, and given  
that file writers always have exclusive serialized access, based upon  
a file-based file_lock--the writer will write a token into the lock  
file upon start of write, and then clear that token upon completion.

If either a reader or writer acquires the file_lock and finds that  
there is a token already written into the lock file, I assume that a  
writer failed to complete and the mapped file is suspect.

Seems like a simple and obvious pattern, which I'm surprised I've  
never used before. I'm happy for suggestions if I've missed something.

Brett it sounds like our applications are quite similar. Feel free to  
email me directly if you want to kibitz.

Andy