两个线程使用相同的 websocket 句柄 - 它会导致任何问题吗？答案

【问题标题】：Two threads using the same websock handle- does it cause any issue?两个线程使用相同的 websocket 句柄 - 它会导致任何问题吗？
【发布时间】：2017-06-28 16:18:55
【问题描述】：

我们有一个 C++ 应用程序来发送和接收 WebSocket 消息

一个线程发送消息（使用WinHttpWebSocketSend）
第二个线程接收（使用WinHttpWebSocketReceive）

但这两个线程使用相同的 WebSocket 句柄。它会引起任何问题吗？我不知道我们是否必须以另一种方式处理它。它在我们的应用程序中工作——我们能够发送和接收消息——但我不知道它在生产环境中是否会出现任何问题。谁有更好的主意？

【问题讨论】：

如果线程没有both 发送或both 接收，那么对于普通套接字来说这不会是一个问题。 Web-sockets 更复杂，所以它实际上取决于函数本身，以及框架级别发生的事情超出你的控制。不幸的是，MSDN 文档没有说明我能找到的任何具体内容，这会导致我使用某种形式的同步。

标签： c++ windows multithreading websocket winhttp

【解决方案1】：

与大多数平台一样，几乎所有 Windows API 系统调用都没有提供线程屏障，只能防止同时访问内核的关键部分。虽然我不能肯定地说（文档似乎没有回答您的明确问题），但如果 WinHTTP API 提供了阻止多个线程相互踩踏的障碍（可以这么说），我会感到惊讶 - 特别是因为它是实际上只是一个“帮助”API，它直接使用了较低级别的 Winsock 东西——我会自己实现必要的障碍。

我也想知道您为什么一开始就以这种方式使用线程。我对 WinHTTP API 基本上一无所知，但我确实注意到 WINHTTP_OPTION_ASSURED_NON_BLOCKING_CALLBACKS 这让我相信您可以实现一种异步方法，这将防止任何线程安全问题开始（并且可能更快且内存效率更高）。

WinHTTP 的回调机制似乎颇具表现力。见WINHTTP_STATUS_CALLBACK。想必你可以简单的使用非阻塞操作，创建一个事件监听器，并将连接句柄与dwContext相关联。不涉及线程。

【讨论】：

感谢您的回答。我们使用线程，这样我们就不需要在等待消息到达时阻塞主线程。我认为我们可以实现回调来接收消息。但我不确定，除了使用线程之外，如何使发送消息异步？
在非阻塞 I/O 模型中，主线程不会阻塞。它直接或间接（通过注册的回调）轮询 I/O 事件。在程序的某个时刻，它会询问 API，“嘿，你有什么要给我的吗？” API 会回答“是”（可能会触发回调）或“否”。在 Windows API 中，这种轮询多次发生在主窗口消息循环期间，有些不为人知。再说一次，我对 WinHTTP 一无所知，但粗略的一瞥会让你觉得你可以做这样的事情。
好吧，让我澄清一下我所说的“不阻塞”的意思……它会在 CPU 工作时阻塞，但不会等待 I/O。通常，只要您不坐在那里等待图像调整大小或其他一些昂贵的任务，就可以完全满足您对套接字 I/O 之类的要求。大多数“处理消息和响应”类型的任务基本上不需要时间。如果需要时间，请在消费者/生产者模型中创建一个线程池，该线程池不会阻塞主线程，并且其工作是做那些昂贵的事情。
发送消息怎么样。我们需要一个单独的线程吗？或者它可以从主线程发送？我们遇到的主要问题是这个。我们有一个 WinHTTP/WebSocket 句柄，我们需要将其用于发送和接收。我理解您使用回调接收的想法。但是发送消息呢？您对此有何想法？