http://blogs.msdn.com/bclteam/archive/2006/10/10/Top-5-SerialPort-Tips-_5B00_Kim-Hamilton_5D00_.aspx
Tip 3. Take care to avoid deadlock when calling Close
on the SerialPort in response to a GUI event.
- An app involving the UI and the SerialPort freezes up when closing the SerialPort
- Deadlock can occur if
Control.Invoke()
is used in serial port event handlers
This is probably the most frustrating SerialPort issue because it may happen so rarely that it’s hard to diagnose. Deadlocks can happen if you have an event handler trying to work with a GUI control while the GUI thread is trying to close the SerialPort. This happens in the following example.
public partial class Form1 : Form
{
SerialPort m_port;
public Form1()
{
InitializeComponent();
m_port = new SerialPort("COM2", 115200);
m_port.DataReceived += new
SerialDataReceivedEventHandler(m_port_DataReceived);
m_port.Open();
}
void m_port_DataReceived(object sender,
SerialDataReceivedEventArgs e)
{
this.Invoke(new EventHandler(delegate
{
m_port.Close();
}));
}
}
This example looks a bit strange, but it forces the deadlock to occur. The typical scenario we encounter is occasional deadlock in an app that has a data received handler trying to update the GUI at the same time the GUI thread is trying to close the SerialPort (for example, in response to the user clicking a Close button).
The reason deadlock happens is that Close
() waits for events to finish executing before it closes the port. You can address this problem in your apps in two ways:
- In your event handlers, replace every
Control.Invoke
call withControl.BeginInvoke
, which executes asynchronously and avoids the deadlock condition. This is commonly used for deadlock avoidance when working with GUIs. - Call
serialPort.Close
() on a separate thread. You may prefer this because this is less invasive than updating yourInvoke
calls.