boost在堆上創建unique_lock而不是堆棧導致mingw崩潰

沒有人知道爲什麼boost唯一鎖對象只能在堆棧上實例化而不在堆上實例化？boost在堆上創建unique_lock而不是堆棧導致mingw崩潰

這完美的作品：

boost::unique_lock<boost::mutex> lock1(mutex1); 
: 
wait_condition.wait(lock1);

但是這將導致在Windows 7 & Windows 8的兩種運行時崩潰使用MinGW編譯後：提前

boost::unique_lock *lock1; 
lock1 = new boost::unique_lock<boost::mutex>(mutex1); 
: 
wait_condition.wait(*lock1);

感謝

來源

2013-02-10 Nathan

你沒有提到你說的是什麼版本的提升，也沒有提到它在哪裏以及如何崩潰。但出於好奇：在堆上創建一個特殊的RAII設施有什麼意義？您可以手動鎖定/解鎖互斥鎖... – 2013-02-10 14:21:51

非常感謝伊戈爾爲了您的迴應。我正在使用boost 1.52.0。 RAII語句讓我思考，然後我意識到我之前應該意識到：在堆上創建它意味着即使在退出創建unique_lock的函數後，鎖也永遠不會超出範圍。當等待返回時，它將重新鎖定，而不會在函數返回時解鎖基於堆的鎖，導致死鎖。在這種情況下，我意味着「應用程序凍結並且不讓我關閉它」。

上述問題已解決。但是，我現在有一個新問題:-)遵循RAII範例並使用堆棧後，一旦有25個子線程處於等待狀態，我的應用程序仍會崩潰。我不知道爲什麼。是否有一些Windows，boost或mingw限制，超過25個線程正在等待互斥鎖？超過25線程的崩潰比上面更糟;它會因Windows錯誤而崩潰：「應用程序被迫以意想不到的方式關閉」。這不會發生少於25線程...

來源

2013-02-16 22:51:59 Nathan

1）值得創建另一個問題並提供一些代碼 - 至少是崩潰的代碼行。 2）「應用程序被迫以意想不到的方式關閉」的消息沒有多大幫助;在調試器中運行您的應用程序，並查看您觀察到的異常。 3）不，沒有25個線程的限制。 – 2013-02-17 14:23:56

boost在堆上創建unique_lock而不是堆棧導致mingw崩潰

回答

相關問題