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

It is a reported bug using some recent boost versions: https://svn.boost.org/trac/boost/ticket/7682

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().

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top