原文地址

• 問題描述
• 查詢原因
  • SerialPort類Open()方法
  • SerialPort類Close()方法
• 死鎖原因
• 解決死鎖
• 總結

問題描述#

前幾天用SerialPort類寫一個串列埠的測試程式，關閉串列埠的時候會讓介面卡死。
參考部落格windows程式介面卡死的原因，得出介面卡死原因：主執行緒和其他的執行緒由於資源或者鎖爭奪，出現了死鎖。

參考知乎文章WinForm介面假死，如何判斷其卡在程式碼中的哪一步？，通過點選除錯暫停，檢視ui執行緒函式棧，直接定位阻塞程式碼的行數，確定問題出現在SerialPort類的Close()方法。

參考文章C# 串列埠操作系列(2) -- 入門篇，為什麼我的串列埠程式在關閉串列埠時候會死鎖 ？

查詢原因#

基於刨根問底的原則，我繼續查詢問題發生的原因。
先看看導致介面卡死的程式碼：

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原始碼，發現這種解決問題的方法還是很有用處的。結果不重要，解決問題的方法是最重要的。