It is a reported bug using some recent boost versions: https://svn.boost.org/trac/boost/ticket/7682
boost interprocess ipc deadlocks
Question
This is my second post in connection with the boost ipc libraries. I'm facing baffling deadlocks so I thought I'll explore some existing examples available on the web
My current problem is just a trial of the example provided @
http://en.highscore.de/cpp/boost/interprocesscommunication.html
#include <boost/interprocess/managed_shared_memory.hpp>
#include <boost/interprocess/sync/named_mutex.hpp>
#include <boost/interprocess/sync/named_condition.hpp>
#include <boost/interprocess/sync/scoped_lock.hpp>
#include <iostream>
int main()
{
boost::interprocess::managed_shared_memory managed_shm(boost::interprocess::open_or_create, "shm", 1024);
int *i = managed_shm.find_or_construct<int>("Integer")(0);
boost::interprocess::named_mutex named_mtx(boost::interprocess::open_or_create, "mtx");
boost::interprocess::named_condition named_cnd(boost::interprocess::open_or_create, "cnd");
boost::interprocess::scoped_lock<boost::interprocess::named_mutex> lock(named_mtx);
while (*i < 10)
{
if (*i % 2 == 0)
{
++(*i);
named_cnd.notify_all();
named_cnd.wait(lock);
}
else
{
std::cout << *i << std::endl;
++(*i);
named_cnd.notify_all();
named_cnd.wait(lock);
}
}
named_cnd.notify_all();
boost::interprocess::shared_memory_object::remove("shm");
boost::interprocess::named_mutex::remove("mtx");
boost::interprocess::named_condition::remove("cnd");
}
This sample code results in a deadlock for me. strace indicates for both the processes:
futex(0x...,FUTEX_WAIT,1,NULL
I'm compiling with gcc 4.7 on ubuntu 12.04
any help / ideas why this is happening ?
PS: Note that if you try this out, and you face the deadlock, keep a stand alone program that just executes the remove commands at the end to clear the shared objects. Else the counter for i would commence from it's current state, and not from 0.
No correct solution
OTHER TIPS
I think it is clear: according to the documentation, notify methods have ho effect, unless there is already a thread (or more) waiting. And in the provided example it can occur, that all processes execute notify_all() before any of them reaches wait().