为什么std :: condition_variable :: notify_one被阻止?

问题描述

由于某种原因，调用signal.notify_one()会阻止当前线程，并且不会返回.我从未听说过这种行为，也不知道如何解决.

For some reason the call signal.notify_one() blocks the current thread and doesn't return. I have never heard about this behavior and I don't know how to resolve it.

{
  std::lock_guard<std::mutex> lock(_mutex);
  _exit = true; // _exit is a std::atomic<bool>
}

std::cout << "before" << std::endl;
_signal.notify_one();
std::cout << "after" << std::endl;

_thread.join();

我正在使用Microsoft Visual C ++ 2015，上面的代码在销毁过程中被调用.

I'm using Microsoft Visual C++ 2015 and the code above is called during destruction.

希望您能指出正确的方向，非常感谢您的帮助！

I hope you can point me in the right direction, thank you much for your help!

推荐答案

好的，我终于能够找到问题所在.为了提供一些背景知识，我目前正在使用一些Poco库(请参阅 http://pocoproject.org/)，并且实现了自己的库Poco :: Channel.经过一番挖掘后，我意识到Poco将所有通道都保留在 static LoggingRegistry中，只有在杀死所有剩余线程之后才将其释放.

Okey, I finally was able to find the problem. To give a bit of background, I'm currently using some Poco libraries (see http://pocoproject.org/) and I implemented my own Poco::Channel. After some digging I realized that Poco keeps all channels in a static LoggingRegistry which is only freed after all remaining threads have been killed.

我最好的猜测是，如果杀死了正在等待 std :: condition_variable 的线程，则 std :: condition_variable 会变为无效.

My best guess is that a std::condition_variable becomes invalid if a thread is killed that is waiting on that std::condition_variable.

无论如何，为了防止出现此问题，必须在main(int argc, char** argv)返回之前致电以下内容:

Anyway, in order to prevent the issue, one has to call the following before the main(int argc, char** argv) returns:

Poco::Logger::shutdown();
Poco::LoggingRegistry::defaultRegistry().clear();

这篇关于为什么std :: condition_variable :: notify_one被阻止?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！