C# SerialPort执行Close死机的问题

情底层都封装好了，串口接收数据缓冲区有数

   
前段时间做了点串口通信的程序，通过串口发送和接收数据，使用C#自带的SerialPort类来实现，实现的机理很简单，很多事情底层都封装好了，串口接收数据缓冲区有数的时候会产生一个事件，通过这个事件去处理串口接收缓冲区的数据，由于串口接收缓冲区数据可能特别多特别频繁，导致产生这个事件也非常频繁，如果这个时候再涉及到窗体显示接收到的数据，那CPU的占用率就噌噌的上去了，而且这个时候还有一个致命的问题就是关闭串口会死机，也就是执行
SerialPort.close()会死机。

ort类来实现，实现的机理很简单，很多事

   
查阅了很多资料，发现这是C#的一个bug。

    还是把达人的解释贴上来。

参考原文：

   
前

    
http://blog.csdn.net/wuyazhe/archive/2009/01/17/3806248.aspx

和接收数据，使用C#自带的SerialPClose的时候死机问题

我只是猜测，Close执行的操作是调用2个API:

SetCommMask(m_hComPort,0);

ort类来实现，实现的机理很简单，很多事

WaitForSingleObject(m_pThread->m_hThread,INFINITE);


m_pThread=NULL;

if(m_hComPort!=INVALID_HANDLE_VALUE)
CloseHandle(m_hComPort);

ort类来实现，实现的机理很简单，很多事

这里的话，SetCommMask操作的时候。如果你的DeviceReceived事件没执行完，里面还有更新界面的操作。就会监听线程在等待，执行到界面操作，界面又要求关闭监听线程然后关闭串口。死锁了。

解决办法：

情底层都封装好了，串口接收数据缓冲区有数

    
一个正确不会死机的串口程序(主要是DataReceived事件里如果要调用ui来显示数据或分析结果的时候。ui的效率不确定，ui可能快。可能慢，可能用户某个操作阻塞中，会导致DataReceived事件执行很长时间，不论如何，这个时间我们无法预料)。

应该在关闭之前执行这句

while (Environment.TickCount - i <
2000 && _isReceiving)
Application.DoEvents();

段时间做了点串口通信的程序，通过串口发送

WriteLine,Write死锁

  
串口必然会读写超时，你无法预测你软件运行的硬件都足够快，串口驱动都效率很高。并且读写超时是正常现象。但是微软的SerialPort类默认的读写超时都是-1，无限等待，如果串口驱动有效率陷阱，超时了。Write和WriteLine就导致软件死锁无法继续使用了。

和接收数据，使用C#自带的SerialP

 

    这是技术上的解决，但是事实上，通过这样的方式解决之后，效率仍然不高，事实上我们可以换一个思路来处理这个问题，在此不再赘述。欢迎登录我的官方博客进行进一步的研究和讨论。