使用 MFC 进行 RS232 通信的“Writefile”永远挂起，但是

Question

我正在维护一个 MFC 程序，它可以通过 RS232 将数据从计算机 A 发送到计算机 B。有时它可以顺利传输数据，但有时它会永远挂起。有两个线程按顺序将相同的数据发送到一个 com 端口。第一个线程成功发送数据，但第二个线程在代码“WriteFile”处挂起。当计算机A上的第二个线程挂在“WriteFile”时，我将一些无意义的数据，例如“1”从计算机B发送回计算机A。然后计算机A上的“WriteFile”挂起停止挂起，计算机B终于看到了数据由计算机 A 上的第二个线程发送。

这里是RS232 log from computer B .

图片显示计算机A上的两个线程在那里发起自己的测试并将消息发送回计算机B。每个线程完成自己的测试并几乎同时向计算机B发送TEST_DONE。但是计算机B只能看到计算机A上第一个线程发送的TEST_DONE（此时第二个线程挂在WriteFile上。）直到我手动从计算机B向计算机A发送“1”。

这是我从计算机 A 向计算机 B 发送消息的代码。 cmd 的长度是 255。

BOOL SerialPort::AutoHandlerRES(unsigned char* cmd){
while(wait_transfer.IsLocked())
    Sleep(1000);
wait_transfer.Lock(); 
CString out;
BOOL RetB;
UCHAR EndChar[2]={0x0D,0x0A};
out=CString(cmd);
DWORD num = out.GetLength()+2;
cmd[num-2]=EndChar[0];
cmd[num-1]=EndChar[1];
RetB=WriteFile(this->m_hCom, cmd, num, &num, NULL);
Sleep(1000);
wait_transfer.Unlock(); 
return RetB;}

我的问题是导致线程 B 挂在“WriteFile”的可能原因是什么？为什么挂起不会发生在线程 A 上？谢谢！

Answer 1

来自the MSDN page about serial communications：

如果一个线程在等待其 I/O 操作完成时被阻塞， 随后调用通信 API 的所有其他线程将 阻塞直到原始操作完成。例如，如果一个 线程正在等待 ReadFile 函数返回，任何其他 发出 WriteFile 函数的线程将被阻塞。

您可能发出阻止 ReadFile 的阻止 WriteFile 完成。在您的情况下，这将是线程之间的竞争条件；写入通常在调用读取之前完成，但并非总是如此。

防止这种情况的最佳方法是不要随便调用ReadFile，而是将其包装在与写入相同的锁中，并在读取之前等待接收 COMM 事件。原始的 Win32 调用是 SetCommMask 和 WaitCommEvent。然后您可以使用ClearCommError 来检测应该读取多少字节（因为接收事件不会告诉您接收了多少数据）。

您还可以使用重叠 IO 来允许同时进行 IO。我觉得它更干净，但并不简单。