[interprocess] Mutex on mac x86 fails
I'm trying to run the following program, which works under Linux, on an
intel
mac:
#include
Andrew Agno wrote:
I'm trying to run the following program, which works under Linux, on an intel mac:
#include
#include #include #include <iostream> using namespace std; namespace bi = boost::interprocess;
int main( int argc, char **argv ) { cout << "Creating mutex" << endl; try { bi::named_mutex directoryMutex( bi::create_only, "MyVeryUniquelyNamedMutex" ); cout << "Creating scoped lock" << endl; bi::scoped_lockbi::named_mutex lock( directoryMutex ); cout << "All reqs met. Destroying mutex" << endl; bi::named_mutex::remove( "MyVeryUniquelyNamedMutex" ); } catch( std::exception &e ) { cout << "Problem encountered: " << e.what() << endl; }
return 0; }
I don't have a MacOs to test the code and I didn't know people was trying to use it with MacOS. But glad to know you are trying. Anyway, you are erasing the mutex and the before the scoped_lock destructor is called. That means that the destructor of the scoped_lock will try to access to a mutex that's already destroyed. This does not seem correct. The "remove" function should be after the mutex is used. Something like: try { { bi::named_mutex directoryMutex( bi::create_only, "MyVeryUniquelyNamedMutex" ); cout << "Creating scoped lock" << endl; bi::scoped_lockbi::named_mutex lock( directoryMutex ); cout << "All reqs met. Destroying mutex" << endl; } bi::named_mutex::remove( "MyVeryUniquelyNamedMutex" ); } catch( std::exception &e ) { cout << "Problem encountered: " << e.what() << endl; } Unless, of course, that you need to destroy the mutex while it's been used (something for which, I have no solution). Regards, Ion
Ion Gaztañaga wrote:
I don't have a MacOs to test the code and I didn't know people was trying to use it with MacOS. But glad to know you are trying. Anyway, you are erasing the mutex and the before the scoped_lock destructor is called. That means that the destructor of the scoped_lock will try to access to a mutex that's already destroyed. This does not seem correct. The "remove" function should be after the mutex is used. Something like:
try { { bi::named_mutex directoryMutex( bi::create_only, "MyVeryUniquelyNamedMutex" ); cout << "Creating scoped lock" << endl; bi::scoped_lockbi::named_mutex lock( directoryMutex ); cout << "All reqs met. Destroying mutex" << endl; } bi::named_mutex::remove( "MyVeryUniquelyNamedMutex" ); } catch( std::exception &e ) { cout << "Problem encountered: " << e.what() << endl; }
Right--whoops. Unfortunately, the code never appears to reach that point. Getting rid of the remove entirely results in the same output: Creating mutex Problem encountered: I also can't debug it using gdb for some reason, which makes this a bit difficult. What platforms would you expect the current code to work on? Thanks.
Andrew Agno wrote:
Ion Gaztañaga wrote: ... Right--whoops. Unfortunately, the code never appears to reach that point. Getting rid of the remove entirely results in the same output: Creating mutex Problem encountered:
I also can't debug it using gdb for some reason, which makes this a bit difficult.
What platforms would you expect the current code to work on?
In theory, I made some changes to extend the UNIX systems supported,
because not all UNIX systems have process-shared mutexes and condition
variables. For those systems (like MacOS, I think) an spin-lock based
emulation (using simple atomic operations) is used. The detection is
made using the header (please update your code to the latest CVS, so
that we can talk about the same code)
Ion Gaztañaga wrote:
If process-shared mutexes are detected the macro
BOOST_INTERPROCESS_POSIX_SHARED_MEMORY_OBJECTS
is defined. Please check if that macro is being defined to know which type of mutex are you using. In theory, you shouldn't get that definition because I think MacOs does not support that. Anyway, I would need a bit of help (gcc or whatever) to know what's going on.
As you expected, that's not defined when I run with the latest CVS version. Can you point me to the files to look at to debug this? Andrew.
participants (2)
-
Andrew Agno -
Ion Gaztañaga