2013-04-10 75 views
1

這是我的第二篇文章,與boost ipc庫有關。 所以我想我會探討一些現有的例子可以在網絡上我面對莫名其妙的死鎖提升interprocess ipc死鎖

我現在的問題只是示例的審判提供@

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"); 
} 

這示例代碼導致我陷入僵局。 strace的指示兩種處理:

futex(0x...,FUTEX_WAIT,1,NULL 

我用gcc 4.7在Ubuntu 12.04

任何幫助/想法編譯爲什麼發生這種情況? PS:請注意,如果您嘗試了這一點,並且遇到了死鎖問題,請保留一個僅在最後執行remove命令以清除共享對象的獨立程序。否則,對於我就從它開始計數器的當前狀態,而不是從0

回答

0

我認爲這是明確的:根據文檔,通知方法有效果,除非已經有線程(或更多)在等待。在所提供的示例中,可能會發生所有進程在其中的任何一個達到wait()之前執行notify_all()。