C#串口关闭SerialPort.Close()导致的卡死
C# 串口操作系列(2) – 入门篇,为什么我的串口程序在关闭串口时候会死锁 ?
https://blog.csdn.net/fengda2870/article/details/51554838
上面的链接给出了提示: 将Invoke变为BeginInvoke。
亲测可行。
private void SerialPort_DataReceived(object sender, SerialDataReceivedEventArgs e) { if (this.InvokeRequired) { this.BeginInvoke(new DataReceived(SerialPort_DataReceived), sender, e); //DataReceived为代理类型 return; } if (!SerialPortRuning) { SerialPortRuning = true; try { // 接收串口数据 } catch (Exception ex) {
} finally { SerialPortRuning = false; } } }
下面还关于串口相关的介绍:
原创 C# 串口操作系列(2) -- 入门篇,为什么我的串口程序在关闭串口时候会死锁 ?
原创 C# 串口操作系列(3) -- 协议篇,二进制协议数据解析
原创 C# 串口操作系列(4) -- 协议篇,文本协议数据解析
出处:https://blog.csdn.net/qq_27508477/article/details/87719668
=======================================================================================
C# 串口关闭时主界面卡死原因分析
问题描述#
前几天用SerialPort类写一个串口的测试程序,关闭串口的时候会让界面卡死。
参考博客windows程序界面卡死的原因,得出界面卡死原因:主线程和其他的线程由于资源或者锁争夺,出现了死锁。
参考知乎文章WinForm界面假死,如何判断其卡在代码中的哪一步?,通过点击调试暂停,查看ui线程函数栈,直接定位阻塞代码的行数,确定问题出现在SerialPort类的Close()方法。
参考文章C# 串口操作系列(2) -- 入门篇,为什么我的串口程序在关闭串口时候会死锁 ?文章的解决方法和网上的大部分解决方法类似:定义2个bool类型的标记Listening和Closing,关闭串口和接受数据前先判断一下。我个人并不太接受这种方法,感觉还有更好的方式,而且文章讲述的也并不太清楚。
查找原因#
基于刨根问底的原则,我继续查找问题发生的原因。
先看看导致界面卡死的代码:
void comm_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
//获取串口读取的字节数
int n = comm.BytesToRead;
//读取缓冲数据
comm.Read(buf, 0, n);
//因为要访问ui资源,所以需要使用invoke方式同步ui。
this.Invoke(new Action(() =>{...界面更新,略}));
}
private void buttonOpenClose_Click(object sender, EventArgs e)
{
//根据当前串口对象,来判断操作
if (comm.IsOpen)
{
//打开时点击,则关闭串口
comm.Close();//界面卡死的原因
}
else
{...}
}
问题就出现在上面的代码中,原理目前还不明确,我只能参考.NET源码来查找问题。
SerialPort类Open()方法#
SerialPort类Close()方法的源码如下:
public void Open()
{
//省略部分代码...
internalSerialStream = new SerialStream(portName, baudRate, parity, dataBits, stopBits, readTimeout,
writeTimeout, handshake, dtrEnable, rtsEnable, discardNull, parityReplace);
internalSerialStream.SetBufferSizes(readBufferSize, writeBufferSize);
internalSerialStream.ErrorReceived += new SerialErrorReceivedEventHandler(CatchErrorEvents);
internalSerialStream.PinChanged += new SerialPinChangedEventHandler(CatchPinChangedEvents);
internalSerialStream.DataReceived += new SerialDataReceivedEventHandler(CatchReceivedEvents);
}
每次执行SerialPort类Open()方法都会出现实例化一个SerialStream类型的对象,并将CatchReceivedEvents事件处理程序绑定到SerialStream实例的DataReceived事件。
SerialStream类CatchReceivedEvents方法的源码如下:
private void CatchReceivedEvents(object src, SerialDataReceivedEventArgs e)
{
SerialDataReceivedEventHandler eventHandler = DataReceived;
SerialStream stream = internalSerialStream;
if ((eventHandler != null) && (stream != null)){
lock (stream) {
bool raiseEvent = false;
try {
raiseEvent = stream.IsOpen && (SerialData.Eof == e.EventType || BytesToRead >= receivedBytesThreshold);
}
catch {
// Ignore and continue. SerialPort might have been closed already!
}
finally {
if (raiseEvent)
eventHandler(this, e); // here, do your reading, etc.
}
}
}
}
可以看到SerialStream类CatchReceivedEvents方法触发自身的DataReceived事件,这个DataReceived事件就是我们处理串口接收数据的用到的事件。
DataReceived事件处理程序是在lock (stream) {...}块中执行的,ErrorReceived 、PinChanged 也类似。
SerialPort类Close()方法#
SerialPort类Close()方法的源码如下:
// Calls internal Serial Stream's Close() method on the internal Serial Stream.
public void Close()
{
Dispose();
}
public void Dispose() {
Dispose(true);
GC.SuppressFinalize(this);
}
protected override void Dispose( bool disposing )
{
if( disposing ) {
if (IsOpen) {
internalSerialStream.Flush();
internalSerialStream.Close();
internalSerialStream = null;
}
}
base.Dispose( disposing );
}
可以看到,执行Close()方法最终会调用Dispose( bool disposing )方法。
微软SerialPort类对父类的Dispose( bool disposing )方法进行了重写,在执行base.Dispose( disposing )前会执行internalSerialStream.Close()方法,也就是说SerialPort实例执行Close()方法时会先关闭SerialPort实例内部的SerialStream实例,再执行父类的Close()操作。
base.Dispose( disposing )方法不作为重点,我们再看internalSerialStream.Close()方法。
SerialStream类源码没有找到Close()方法,说明没有重写父类的Close方法,直接看父类的Close()方法,源码如下:
public virtual void Close()
{
Dispose(true);
GC.SuppressFinalize(this);
}
SerialStream父类的Close方法调用了Dispose(true),不过SerialStream类重写了父类的Dispose(bool disposing)方法,源码如下:
protected override void Dispose(bool disposing)
{
if (_handle != null && !_handle.IsInvalid) {
try {
//省略一部分代码
}
finally {
// If we are disposing synchronize closing with raising SerialPort events
if (disposing) {
lock (this) {
_handle.Close();
_handle = null;
}
}
else {
_handle.Close();
_handle = null;
}
base.Dispose(disposing);
}
}
}
SerialStream父类的Close方法调用了Dispose(true),上面的代码一定会执行到lock (this) 语句,也就是说SerialStream实例执行Close()方法时会lock自身。
死锁原因#
把我们前面源码分析的结果总结一下:
- DataReceived事件处理程序是在lock (stream) {...}块中执行的
- SerialPort实例执行Close()方法时会先关闭SerialPort实例内部的SerialStream实例
- SerialStream实例执行Close()方法时会lock实例自身
当辅助线程调用DataReceived事件处理程序处理串口数据但还未更新界面时,点击界面“关闭”按钮调用SerialPort实例的Close()方法,UI线程会在lock(stream)处一直等待辅助线程释放stream的线程锁。
当辅助线程处理完数据准备更新界面时问题来了,DataReceived事件处理程序中的this.Invoke()一直会等待UI线程来执行委托,但此时UI线程还停在SerialPort实例的Close()方法处等待DataReceived事件处理程序执行完成。
此时,线程死锁发生,两边都执行不下去了。
解决死锁#
网上大多数方法都是定义2个bool类型的标记Listening和Closing,关闭串口和接受数据前先判断一下。
我的方法是DataReceived事件处理程序用this.BeginInvoke()更新界面,不等待UI线程执行完委托就返回,stream的线程锁会很快释放,SerialPort实例的Close()方法也无需等待。
总结#
问题最终的答案其实很简单,但我在查阅.NET源码查找问题源头的过程中收获了很多。这是我第一次这么深入的查看.NET源码,发现这种解决问题的方法还是很有用处的。结果不重要,解决问题的方法是最重要的。
出处:https://www.cnblogs.com/timefiles/p/CsharpSerialPortDeadlockOnClose.html
关注我】。(●'◡'●)
如果,您希望更容易地发现我的新博客,不妨点击一下绿色通道的【因为,我的写作热情也离不开您的肯定与支持,感谢您的阅读,我是【Jack_孟】!
本文来自博客园,作者:jack_Meng,转载请注明原文链接:https://www.cnblogs.com/mq0036/p/11528639.html
【免责声明】本文来自源于网络,如涉及版权或侵权问题,请及时联系我们,我们将第一时间删除或更改!
posted on 2019-09-16 17:45 jack_Meng 阅读(7362) 评论(0) 编辑 收藏 举报