gpt4 book ai didi

c# - SerialPort 类偶尔卡在 Dispose 上

转载 作者:可可西里 更新时间:2023-11-01 08:21:01 25 4
gpt4 key购买 nike

我编写了一个 .net 4.0 控制台应用程序,它定期与 GSM 调制解调器对话以获取收到的 SMS 消息的列表(它是一个 USB 调制解调器,但代码通过串行端口驱动程序连接到它并发送 AT 命令 -顺便说一句,它是 Sierra Wireless 调制解调器,但我无法更改它,而且我有最新的驱动程序)。发生的事情是在一段时间后(可能是几小时,也许是几天)它就停止工作了。这是一个日志片段...

2012-04-17 23:07:31 DEBUG Modem Check (108) - Executing AT command 'AT+CPMS="ME"'...
2012-04-17 23:07:31 DEBUG Modem Check (108) - Finished executing 'AT+CPMS="ME"'
2012-04-17 23:07:31 DEBUG Modem Check (108) - Detaching event handlers for 'COM13'
2012-04-17 23:07:31 DEBUG Modem Check (108) - Disposing the SerialPort for 'COM13'

日志到此结束 - 仅此而已,尽管我希望至少再看到一条语句,这里是相关代码:

internal T Execute()
{
var modemPort = new SerialPort();
T ret;

try
{
modemPort.ErrorReceived += ModemPortErrorReceived;

modemPort.PortName = _descriptor.PortName;
modemPort.Handshake = Handshake.None;
modemPort.DataBits = 8;
modemPort.StopBits = StopBits.One;
modemPort.Parity = Parity.None;
modemPort.ReadTimeout = ReadTimeout;
modemPort.WriteTimeout = WriteTimeout;
modemPort.NewLine = "\r\n";
modemPort.BaudRate = _descriptor.Baud;

if (!modemPort.IsOpen)
{
modemPort.Open();
}

ret = _command.Execute(modemPort, _logger);

_logger.Debug("Detaching event handlers for '{0}'",
_descriptor.PortName);

modemPort.ErrorReceived -= ModemPortErrorReceived;

_logger.Debug("Disposing the SerialPort for '{0}'",
_descriptor.PortName);
}
catch (IOException ex)
{
_logger.Error(ex.Message);

throw new CommandException(
string.Format(CultureInfo.CurrentCulture,
ModemWrapperStrings.COMMAND_ERROR,
ex.Message),
ex);
}
catch (UnauthorizedAccessException ex)
{
_logger.Error(ex.Message);

throw new CommandException(
string.Format(CultureInfo.CurrentCulture,
ModemWrapperStrings.COMMAND_ERROR,
ex.Message),
ex);
}
finally
{
modemPort.Dispose();

_logger.Debug("Modem on port '{0}' disposed",
_descriptor.PortName);
}

return ret;
}

如您所见,它卡在 SerialPort 类的 Dispose 方法上。

我做了一些谷歌搜索,然后遇到了这个问题:Serial Port Close Hangs the application从这个线程:serial port hangs whilst closing .共识似乎是在不同的线程中关闭端口,但这是否仅适用于表单应用程序?在我的例子中,我有一个简单的控制台应用程序,所以我认为它不适用(它只是在主线程中循环运行)。我什至不确定这实际上是这个问题(我的感觉是调制解调器的串行端口驱动程序更有可能存在问题,但我不知道,也许我对调制解调器不公平)。据我所知,我有三个选择:

  1. 在不同的线程中关闭端口
  2. 在关闭港口之前延迟
  3. 永远打开端口

我真的不喜欢这些解决方法中的任何一个,但我正在考虑让端口保持打开状态,看看会发生什么(我觉得它会泄漏内存或更糟,暴露调制解调器的其他一些问题,但也许我我只是悲观,如果是这种情况,我可能可以每 24 小时关闭一次,然后重新打开它)所以我的问题是......

此代码是否存在可能导致此行为的替代问题,或者是否存在我上面概述的替代解决方法?

最佳答案

SerialPort 有点容易死锁。到目前为止,最常见的原因是您发现的原因,它是通过在 DataReceived 事件处理程序中使用 Invoke() 触发的。这里显然不是你的情况。

这些死锁与 SerialPort 在幕后启动的工作线程有关。该线程有助于检测端口上的异步事件,底层 native winapi 是 WaitCommEvent()。该工作人员使 DataReceived、PinChanged 和 ErrorReceived 事件起作用。请注意您如何使用 ErrorReceived。

Dispose() 方法与 Close() 方法做同样的事情,它向工作线程发出退出信号。然而,缺陷是它不等待线程退出。这是一个麻烦的秘诀,在备注部分的 MSDN 文章中明确记录了 SerialPort.Close() 的那种:

The best practice for any application is to wait for some amount of time after calling the Close method before attempting to call the Open method, as the port may not be closed instantly.

坦率地说,这是“最佳实践”建议中最糟糕的做法,因为它根本没有具体说明您应该等待多长时间。有充分的理由,没有保证的安全值(value)。等待一两秒钟应该是 99.9% 的好。 0.1% 故障模式发生在机器负载很重并且工作线程根本没有足够的周期来及时检测关闭条件时。当然是完全不可调试的。

解决这个问题,只在程序开始时打开串行端口并在退出时关闭它。除了线程问题之外,这还可以确保您不会在另一个程序跳入并从您那里窃取端口时随机失去对该端口的访问权。请注意,实际上不再需要关闭端口,如果您不需要,Windows 会自行处理。

关于c# - SerialPort 类偶尔卡在 Dispose 上,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10209090/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com