[boost] [inteprocess] Using named_mutex on Windows 7

Subject: [boost] [inteprocess] Using named_mutex on Windows 7
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-11-18 19:50:49

I wrote a program more than 3 years ago where I used 
boost::interprocess_named_mutex to protect more than one instance of the 
same process from running the same sequence of code at the same time. 
The program appears to run fine under Windows XP and Windows Vista but 
occasionally locks up waiting for the locked mutex to unlock on Windows 
7. The code looks like this:

-------------------------------------------------------------------

boost::interprocess::named_mutex 
cmutex(boost::interprocess::open_or_create_t(),"MyMutexName");

{
 
boost::interprocess::scoped_lock<boost::interprocess::named_mutex> 
cscoped(cmutex);

// Code here which must be run one at a time.

}

-------------------------------------------------------------------

Under Windows 7 the code occasionally hangs on the scoped_lock 
instantiation, which of course I can not have. I notice there is a file 
in the temporary directory ( TMP or TEMP environment variable ) which is 
being used by interprocess, and after that file is manually deleted, the 
program no longer hangs on the scoped_lock instantiation.

Is there a reason for this problem on Windows 7 ?

I know that Windows 7 has global and local named mutexes and only by 
prefacing a named mutex name with global\ is the mutex truly global. I 
do not know if this is causing the problem on Windows 7. It does seem as 
if something in the file in the temporary directory is telling 
inteprocess that "MyMutexName" is still locked when the hangup occurs, 
but I would have expected that when acoped_lock goes out of scope, it 
handles resetting that file to the correct state. I wonder if this has 
something to do with UAC/file permissions in Windows 7, where the 
process somehow can no longer write to the file in the temporary 
directory afte creating it.

Is this a known interprocess problem, perhaps fixed in a later release ? 
I wrote my code before Windows 7 even came out, recompiled it for 
Windows 7, but did not update the version of Boost I was using for the 
program ( Boost 1.35 ). Maybe I need to do that ? I would certainly be 
willing to do that if I knew that this was a problem with interprocess 
in Boost 1.35 that has subsequently been fixed in a later version of Boost.