为什么在SerialPort.Open和Close之前使用Thread.Sleep（）？

我注意到我在SerialPort关闭和打开时读取的示例代码，人们会在SerialPort.Open（）和Close（）之前添加Thread.Sleep（1000）。如下：

Thread.Sleep(1000); serialPort1.Open(); /* some code */ Thread.Sleep(1000); serialPort1.Close();

我在任何地方都找不到任何解释。为什么人们在打开或关闭之前使用Thread.Sleep来阻塞串口？它是出于某种计时目的吗？我是否应该在读取或写入串行端口时放置Thread.Sleep？

当您打开一个端口时，SerialPort类会启动一个新线程，负责（通过WaitCommEvent Windows API函数）等待串口活动（例如数据到达）并向您的处理程序发送相应的事件。这就是DataReceived之类的事件实际发生在辅助线程上的原因。

当您关闭端口时，Close（）调用立即返回，但是辅助线程需要一些时间才能减速。

如果在调用Close后尝试过快地重新打开端口，并且线程尚未停止，则SerialPort实例不处于可以开始新连接的状态。

请注意SerialPort.Close的MSDN文档：

任何应用程序的最佳实践是在尝试调用Open方法之前等待一段时间后再调用Close方法，因为端口可能不会立即关闭。

您可以跟踪何时关闭端口，并在再次打开它之前确保已经过了一些任意超时。

在读/写之前无需睡觉，但要记住一些怪癖：

请记住.NET BCL中的SerialPort类仍然依赖于底层的Win32 API，我认为自从最初的实现以来，它已经得到了很多微软的喜爱。

有关更多信息，请参阅

每个SerialPort对象只能存在一个打开的连接。任何应用程序的最佳实践是在尝试调用Open方法之前等待一段时间后再调用Close方法，因为端口可能不会立即关闭。

看看这个链接。

我在C＃中完成了一些串行I / O程序，我认为我从未添加过这样的睡眠。我没有经历过任何不良影响（需要注意的是我的应用程序从未试图快速连续打开和关闭串口）

你绝对不应该在阅读或写作之前睡觉。