boost :: interprocess :: scoped_lock鎖內應用程序崩潰

我正在使用boost :: interprocess :: scoped_lock，如果應用程序崩潰的原因在範圍內的互斥體未被釋放。下次執行應用程序（無需重新啓動計算機），互斥鎖被鎖定。boost :: interprocess :: scoped_lock鎖內應用程序崩潰

這是打算如何工作？我給出了一個簡單的例子，下面的代碼。

{ 
    boost::interprocess::named_mutex lockMutex(boost::interprocess::open_or_create, "lockName"); 
    boost::interprocess::scoped_lock<boost::interprocess::named_mutex> lock(lockMutex); 
    //crash here 
}

最後我做一個超時像下面。任何人都可以想出一個不限制鎖定時間的解決方案？

boost::interprocess::named_mutex named_mtx(boost::interprocess::open_or_create, lockName.c_str()); 

    while(true) 
    { 
     if(named_mtx.try_lock()) 
     { 
      break; 
     } 

     if(!named_mtx.timed_lock(boost::get_system_time() + boost::posix_time::milliseconds(TIMEOUT_MILLISECONDS))) 
     { 
      named_mtx.unlock(); 
     } 
    }

來源

2011-06-07 thenail

這似乎完全邏輯來我:)

當你的應用程序崩潰，它映射到您的操作系統進程間通信機制（IPC）的互斥體不會被釋放。當您的應用程序重新啓動時，它會嘗試獲取互斥鎖而無法成功！

我想你的應用程序有不同的子系統（進程）需要同步。

如果某個子系統發生崩潰而無法正確管理鎖，則必須制定全局策略。例如，如果其中一個子系統崩潰，它應該嘗試在啓動時解鎖互斥鎖。當其他子系統使用該鎖時，可能會非常棘手。超時也可以提供幫助。在任何情況下，你必須設計的政策，記住你的任何進程可以崩潰，同時鎖定互斥鎖...

當然，如果你不需要進程間鎖定，使用簡單的有限範圍的鎖:)

my2c

來源

2011-06-07 18:10:44 neuro

Boost使用文件模擬指定的互斥鎖。如果應用程序崩潰 - 文件保留在文件系統中... OS互斥鎖不使用。檢查消息來源...... – 2016-03-03 10:46:38

@Victor：無論使用何種操作系統機制，正如我所回答的那樣，問題在於沒有管理問題的策略。無需查看庫代碼即可知曉。提升使用文件來實現命名互斥體不是問題，問題是共享資源的管理... – neuro 2016-03-07 09:48:36

@Victor：我壓制了關於IPC特定命令的註釋。 – neuro 2016-03-07 09:52:06

boost :: interprocess :: scoped_lock鎖內應用程序崩潰

回答

相關問題