現在的C++編程非常的抽象，這對程序員來說非常好。當然，這是在代碼運行一切都正常的情況下。不幸的是，C++在嵌入式中引入了一個穩定性問題，許多程序員都還沒有意識到這個問題。本文解釋了C++編程時中斷內存分配的問題，并提出了解決方案。

這里談到的內存分配在主程序和中斷服務例程中都被使用。在很多情況下，這個災難性的問題會影響到最終產品，使系統變得不穩定、崩潰或故障是隨機的，很難發現，但又沒有罕見到可以忽略。事實上，現在可能有成千上萬的系統存在這個問題。

背景 //

在早期，嵌入式設備的程序是用匯編語言編寫的。很繁瑣，容易出錯，而且非常依賴目標CPU，一旦嵌入式系統的C編譯器可用，開發人員就會切換到更高級別的語言。

高級語言編程的第一個廣泛選擇是C語言。在C語言中，程序員不必考慮機器級別，即針對目標CPU的個別指令。這樣做的好處是開發人員可以專注于要解決的實際算法或問題。與匯編語言相比，C源代碼更容易閱讀、更緊湊，也更容易維護。

但是放棄控制是有代價的，因為程序員與機器和目標系統中正在發生的事情之間的距離自然會越來越遠。當然，代碼容易編寫，但是對于編譯器如何將源代碼轉換為要執行的指令的控制要少得多。

從C遷移到C++又向前邁進了一步。抽象級別更高，程序源代碼變得更加緊湊。與此同時，目標系統中究竟發生了什么變得更加不清楚。在許多情況下，被調用的函數對程序員來說不再可見。

內存碎片 //

在C程序中，對于應用程序的編程來說，是否使用堆，在哪里以及如何使用是很清晰的。這基本上是一個內存塊的分配和釋放，如alloc()和free()。

堆存在一些問題，這就是許多應用程序避免使用它們的原因。最大的問題之一是碎片化。只有在內存不多的情況下，這才會成為一個問題，所以在開發PC應用程序時，這也不是一個問題。但是在嵌入式系統中，碎片可能導致系統內存耗盡的情況，不是因為沒有可用的內存，而是由于碎片沒有足夠大小的可用塊。雖然這可能是一個嚴重的問題，但大多數程序員都意識到了這一點，這不是本文的重點。

可重入代碼 //

堆管理例程不是可重入的，因為它們管理全局內存池。這意味著需要對堆管理例程進行序列化，以確保對一個例程的調用不會被對同一個或另一個堆管理例程的調用中斷(在臨界段)。對于多任務環境(RTOS)中的線程，可以使用信號量或互斥量來保證這一點。

中斷 //

在編寫桌面C++應用程序時，這存在問題，因為應用程序不處理中斷。這些由底層操作系統處理。嵌入式系統開發人員沒有這樣的待遇，中斷服務例程(ISR)是應用程序的一部分。這也是讓事情變得棘手和出錯的地方。

ISR中斷正常的程序執行。如果它中斷堆操作，然后使用堆操作本身，它可能會造成系統不穩定，例如將同一塊內存兩次分配給請求它的ISR和請求它的正常程序。這種類型的沖突會產生不可預測的行為，包括系統不穩定和崩潰，因此可能是災難性的行為。

這個問題很少在測試中出現。然后，一個bug就會進入到最終產品中，使系統變得不穩定，導致隨機崩潰，幾乎不可能重現。即使問題已經很明顯了，要找出原因就像大海撈針。

解決方法 //

麻煩一點的方法是確保應用程序不會從ISR中調用堆操作函數。這可以通過只在ISR中使用C來實現，同時確保沒有調用alloc()或free()函數。

不幸的是，這并不容易，特別是ISR很可能會調用其他函數，這些函數現在也需要保證是沒有堆操作的。另一個問題是，即使您的代碼能夠做到這一點，另一個團隊成員可能會引入C++，從而產生問題。

所以這說起來容易做起來難。但如果你決定走這條路，有一個建議：

通過在“Lock”操作中使用一段代碼查看CPU的中斷狀態，應該確保在調試版本中，你的內存管理不是從中斷上下文(ISR)中調用的。這樣就不能避免關鍵問題，而是可以在開發過程中發現，而不會進入最終產品。

更簡單的一種辦法是確保內存分配函數是中斷安全的簡單方法是在堆操作的關鍵部分禁用中斷，這需要工具鏈的配合。在Embedded Studio中，這是默認的選項。換句話說，這個問題在使用Embedded Studio時不存在。Embedded Studio還提供了另一個鎖定選項，稱為“User”，由用戶負責控制堆鎖定，以便針對多核cpu或高度時間關鍵的應用程序調優系統。

審核編輯：湯梓紅