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.