我是一个C ++开发人员，直到最近我还不得不创build一个针对Windows的应用程序时，他主要在Solaris和Linux上进行编程。
我一直在使用基于TCP套接字支持的C ++ I / Ostream的通信devise。 这个devise是基于从stream中连续读取单个线程（大部分时间阻塞在套接字读取中等待数据），而其他线程通过同一个stream发送（通过互斥体同步）。
当移动到Windows时，我select使用boost :: asio :: ip :: tcp :: iostream来实现套接字stream。 我惊讶地发现上面的multithreadingdevise导致了Windows上的死锁。 看起来， operator<<(std::basic_ostream<...>,std::basic_string<...>)声明了一个“Sentry”，它locking整个stream的input和输出操作。 由于我读取的线程总是在stream中等待，所以当创build这个Sentry时，从其他线程发送死锁。
这里是运算符<<和Sentry构造过程中调用堆栈的相关部分：
... ntdll.dll!7c901046() CAF.exe!_Mtxlock(_RTL_CRITICAL_SECTION * _Mtx=0x00397ad0) Line 45 C CAF.exe!std::_Mutex::_Lock() Line 24 + 0xb bytes C++ CAF.exe!std::basic_streambuf<char,std::char_traits<char> >::_Lock() Line 174 C++ CAF.exe!std::basic_ostream<char,std::char_traits<char> >::_Sentry_base::_Sentry_base(std::basic_ostream<char,std::char_traits<char> > & _Ostr={...}) Line 78 C++ CAF.exe!std::basic_ostream<char,std::char_traits<char> >::sentry::sentry(std::basic_ostream<char,std::char_traits<char> > & _Ostr={...}) Line 95 + 0x4e bytes C++ > CAF.exe!std::operator<<<char,std::char_traits<char>,std::allocator<char> >(std::basic_ostream<char,std::char_traits<char> > & _Ostr={...}, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & _Str="###") Line 549 + 0xc bytes C++ ...
如果istream和ostream组件分开locking，我会好的，但情况并非如此。
是否有可以使用的stream操作符的替代实现？ 我可以指示它不锁吗？ 我应该实施自己的（不知道如何做到这一点）？
任何build议，将不胜感激。
（平台是Windows 32位和64位。在Visual Studio 2003 Pro和2008 Express中观察到的行为）
根据boost文档[1]，使用两个线程访问没有互斥的对象是“不安全的”。 仅仅因为它在Unix平台上工作并不能保证它能在Windows平台上工作。
所以你的选择是：
[1] http://www.boost.org/doc/libs/1_39_0/doc/html/boost_asio/overview/core/threads.html
这个问题已经持续了很久。 即使有机会我会被嘲笑，我要报告我最终做了什么。
我已经确定问题是两个线程在尝试访问单独的读写操作中的iostream对象时发生死锁。 我可以看到Visual Studio实现的字符串流插入和提取操作符都声明了一个Sentry，它锁定了与正在操作的流相关的流缓冲区。
我知道，对于这个死锁问题的流，流缓冲区实现是boost :: asio :: basic_socket_streambuf。 我检查了实现，看到读写操作（下溢和溢出）实际上在不同的缓冲区上运行（get和put）。
通过上面的验证，我选择了简单地绕开这个应用程序的锁定。 为此，我使用项目特定的预处理器定义来排除锁定哨兵的basic_istream实现中的锁定代码：
class _Sentry_base { // stores thread lock and reference to input stream public: __CLR_OR_THIS_CALL _Sentry_base(_Myt& _Istr) : _Myistr(_Istr) { // lock the stream buffer, if there #ifndef MY_PROJECT if (_Myistr.rdbuf() != 0) _Myistr.rdbuf()->_Lock(); #endif } __CLR_OR_THIS_CALL ~_Sentry_base() { // destroy after unlocking #ifndef MY_PROJECT if (_Myistr.rdbuf() != 0) _Myistr.rdbuf()->_Unlock(); #endif }
潜在上升空间：
下行：
我计划通过在代码和项目文档中大声记录这一点来缓解后一点。
我意识到可能有一个更优雅的解决方案，但为了方便起见，我在尽职调查后选择了一个直接的解决方案来了解影响。
也许你可以自己实现一个锁定层？ IE，有一个单独的istream和ostream ，当你被调用的时候你自己锁住了。 定期检查两者是否都解锁，然后从一个读入另一个。
写完之后，你是否明确地刷新了流？ 这篇博文意味着你的数据可能会简单地被“卡住”在缓冲区中。 如果这是真的，那么也许你似乎陷入僵局，因为没有什么可读的。 添加stream << std::flush到您的发送操作结束。
博客文章建议的另一种（尽管效率较低）解决方案是关闭流的输出缓冲：
stream.rdbuf()->pubsetbuf(0, 0);
我知道这是一个古老的问题，但我必须自己做这个！
我的情况比较复杂，因为这是我自己的流氓，但是你可以通过这样做来解决这个问题：
std::ostream &operator<<(std::ostream &x, std::string &y) { x.rdbuf()->_Unlock(); x << y.c_str(); }
它被优先调用std :: version。
你当然必须为每一个Windows操作符做这个，它调用_Lock和（在我的情况下）所有你的streambuf中的读/写调用。