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崩溃

回答

相关问题