如何允许线程2在线程1中打开的端口上进行通信？ [英] How can I allow thread 2 to communicate on the port I opened in thread 1?

问题描述

我尝试使用CLI C ++程序（在Windows上运行但不使用Windows API）中使用两个不同的线程与同一端口进行通信。端口是USB端口（通向转换器到RS-232，然后到另一个设备）。我可以使用 OpenCom（）和 Transmit（）在我的主线程中成功建立端口通信。

然后我调用 newThreadFunc（）（在另一个DLL中定义），它在一个单独的线程中运行（我们称之为回调线程）并调用一个回调函数。在该回调函数中，我再次调用 Transmit（），但现在返回一个错误（由DLL定义）：Port not ready（CreateFile） p>

以下是简化的伪代码：

  #include h//包含OpenCom（）& Transmit（）
 
 const short comPort = 3; // COM端口号（全局）
 
 int main（int argc，char * argv []）{
 
 OpenCom //打开端口
 Transmit（command）; //其中command代表一些命令
 
 newThreadFunc（taskHandle）; //创建新的回调线程并调用callbackFunc 
 getchar（）; //等待其他线程运行
 return 0; 
} 
 
 signed long __cdecl callbackFunc（params）{
 Transmit（command）; //错误：端口未就绪（CreateFile）
 OpenCom（comPort）; //错误：端口已打开（CreateFile）
} 
  

code> OpenCom 在回调线程，我得到这个错误：端口已经打开（CreateFile）。所以回调线程可以看到端口是开放的，但不能在其上通信。我知道我应该用mutex或类似的方式管理端口通信，但是为什么回调线程不能在端口上通信的原因是什么？如何允许回调线程在主线程中打开的端口上进行通信？

解决方案

>非常的简单设备，他们只是支持一个不透明的字节流。没有协议允许两个线程或两个应用程序共享端口。没有什么像TCP允许通过单个网络连接到特定端口号的逻辑连接。在 OSI模型中，串行端口占据了底层的物理层。没有任何标准曾经出现在其上面构建图层，没有人同意第2层应该是什么样子。

所以如果操作系统实际上允许你这样做，那么结果将是非常糟糕的。一个应用程序或线程将窃取输入意味着另一个，这永远不会达到一个好的结局。所以你真的做必须自己照顾这个并打开端口一次。使用某种方案来仲裁对端口的访问，以确定哪个线程获得输入。像互斥。或者您创建的网络层具有逻辑目标地址，在总线协议中非常常见。这可以像消息中的单个字节一样简单。但是，当然增加了实现数据链路层和指定消息帧格式的要求，因此该字节可以可靠地读取。很常见，每个人都旋转自己。

I'm trying to communicate with the same port using two different threads in a CLI C++ program (running on Windows but not using the Windows API). The port is a USB port (that leads to a converter to RS-232 and then to another device). I can successfully establish port communications in my main thread using OpenCom() and Transmit(), functions provided in a DLL by the manufacturer of those devices.

I then call newThreadFunc() (defined in another DLL), which runs in a separate thread (let's call it the callback thread) and calls a callback function. In that callback function, I call Transmit() again, but now it returns with an error (defined by the DLL): "Port not ready (CreateFile)".

Here is the simplified pseudo-code:

#include "Device.h"            // contains OpenCom() & Transmit()

const short comPort = 3; // COM port number (global)

int main(int argc, char* argv[]) {

    OpenCom(comPort);          // Open the port
    Transmit(command);         // where "command" represents some command

    newThreadFunc(taskHandle); // Creates new "callback thread" and calls callbackFunc
    getchar();                 // wait while other thread runs
    return 0;
}

signed long __cdecl callbackFunc (params) {
    Transmit(command);         // error: "Port not ready (CreateFile)"
    OpenCom(comPort);          // error: "Port already open (CreateFile)"
}

If I call OpenCom in the callback thread, I get this error: "Port already open (CreateFile)". So the callback thread can see that the port is open but cannot communicate on it. I know I should manage the port communications somehow with a mutex or similar, but what's the reason why the callback thread can't communicate on the port? And how can I allow the callback thread to communicate on the port I opened in the main thread?

解决方案

Serial ports are very simple devices, they just support an opaque stream of bytes. There is no protocol to allow two threads or two applications to share a port. Nothing like TCP that allows a logical connection to a specific port number across a single network connection. In the OSI model, a serial port occupies the bottom one, the physical layer. With no standard that ever emerged to build layers on top of it, nobody ever agreed on what layer #2 should look like. The Hayes AT protocol for modems is as far as it ever got.

So if the OS would actually allow you do this then the outcome would be very poor. One app or thread would steal the input meant for another, that can never come to a good end. So you really do have to take care of this yourself and open the port once. With some kind of scheme to arbitrate access to the port that determines which thread gets the input. Like a mutex. Or a network layer you create that has a logical destination address, very common in bus protocols. That can be as simple as a single byte in a message. But of course adding the requirement that you implement the data link layer and specify a message frame format so this byte can reliably be read. Very common as well, everybody spins their own.

这篇关于如何允许线程2在线程1中打开的端口上进行通信？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！