C＃串行數據接收事件餓了

Question

我在現有應用程序的基礎上構建並使用C＃SerialPort類來處理USB上的數據事務。 我注意到，當應用程序產生許多長時間運行的線程，並且未使用TaskCreation LongRunning選項將它們指定為長時間運行時，這些線程可以暫時使SerialPort DataReceived事件死機，並防止它觸發一些擴展的時間。

這是C＃處理線程管理方式的一些根本結果嗎？

有什么方法可以增加DataReceived事件的“優先級”嗎？

如果不是，那么“解決方案”是否應該有一個不斷運行的線程來輪詢串行端口數據標志，而不是使用DataReceived事件？

謝謝！

Answer 1

這是非常基本的，是的。 您的DataReceived事件處理程序由線程池線程調用。 如果您有許多活動出於其他目的而活動（例如非LongRunning的任務），那么可能要過一會兒，事件處理程序才能開始運行。 正常的操作系統調度算法在完成I / O調用時提高線程的優先級，在這里無效，它只能高效地調度tp線程：）

這是一個基本的消防水帶問題，您期望機器完成的工作超出其性能。 了解任務是否正確的主要方法是查看任務管理器。 CPU使用率應固定為100％。 如果它要少得多，則說明您沒有有效地使用線程池， 某些任務正在占用池，但執行的代碼不足，通常是因為它們在同步對象或I / O操作上等待的時間過多。 您應該通過使用純線程或TaskCreationOptions.LongRunning來解決此問題。 ThreadPool.SetMinThreads（）通常被引用為一種快速修復方法，它是一個骯臟的方法。 升級機器規格，增加內核數量，是一種更清潔的方法。

Answer 2

有一個甚至更簡單的解決方案-按照設備驅動程序編寫者的預期方式使用串行端口。 串行端口通信絕對不保證使用人工創建的線程或從線程池使用的工作線程。 我鼓勵您閱讀我的整個博客文章“如果必須使用.NET System.IO.Ports.SerialPort” ，但是簡短的版本是將BaseStream.ReadAsync與async + await一起使用，如果您使用的是.NET的最新版本，和BaseStream.BeginRead ，否則帶有回調。

另外，感謝您為我提供DataReceived事件令人恐怖的另一個原因。 清單越來越長。