能源控制器信號量死鎖問題分析及解決方案

張晨宏 鄔科科

摘 要：隨著我國智能電網的快速發展，傳統采集設備已無法完全滿足當前需求。配電臺區是營銷與生產的交匯點，傳統模式下，營銷與生產雙方需要在臺區側分別安裝集中器和配變終端（TTU）兩種設備，但仍存在諸多問題。在此背景下，融合了Ⅰ型集中器、專變終端、二次回路巡檢儀和配電終端功能的能源控制器（ECU）應運而生。但在該全新產品開發過程中，由于技術新、難點多，各類問題頻出，例如液晶顯示菜單無序切換問題等，究其根本，實為信號量死鎖導致?；诖?，提供了一套能源控制器信號量死鎖的解決方案。

關鍵詞：能源控制器;信號量;死鎖

0 引言

能源控制器具備數據采集、智能費控、時鐘同步、精確計量、回路狀態監測、停電事件上報等多種功能[1]，不同功能從軟件層面被劃分成了不同的App。當前能源控制器液晶顯示菜單存在無序切換的問題，通過分析發現根源是硬件接口層使用的信號量在第三方容器App中失效。進一步深挖后發現，目前使用的信號量機制中，當進程在持有鎖期間終止時，會造成信號量死鎖，導致其他進程異常，僅能通過重啟恢復。

本文通過對死鎖問題的深度分析，提出一種將線程鎖與進程鎖組合的方式，來實現多線程和多進程下都適用的信號量，從而避免死鎖問題。

1 信號量死鎖問題概述

1.1 ? ?問題背景

能源控制器應用容器技術隔離運行多個App，這就對多進程間資源共享的同步措施提出了更高的要求。解決問題的關鍵在于：什么時候可以在不同進程間共享某個信號量。

在目前能源控制器的App框架下，被不同進程訪問的Hal層，需要使用二值信號量對臨界區資源進行保護。

不同的進程總是能夠訪問同一個有名信號量，只要它們在調用sem_open時指定相同的名字。即使對于某個給定名字的sem_open調用，在每個調用進程中可能返回不同的指針，使用該指針的信號量函數（例如sem_post和sem_wait）所引用的仍然是同一個有名信號量。

1.2 ? ?信號量在容器中失效的原因分析

在使用相同名字的前提下，需要了解有名信號量保存的具體位置。跟消息隊列類似，它保存在/dev/shm目錄中。在這個目錄中可以找到被創建了的、但是沒有調用sem_unlink的信號量。

每個Docker容器都有一個本地存儲空間，用于保存層疊的鏡像層（Image Layer）以及掛載的容器文件系統。容器內外的進程要達到信號量共用的目的[2]，需要容器與主機共享數據。用法是使用-v選項將host已經存在的目錄或者文件掛載到容器。

通過對信號量未失效容器和信號量失效容器的掛載配置信息的比對，可以發現在信號量未失效容器中，容器同時掛載了主機的/dev和/dev/shm目錄，而信號量失效容器只掛載了主機的/dev目錄。這兩個目錄在主機上是兩個不同的掛載點，文件系統也不同，/dev/shm是Linux中動態大小的一個內存文件系統分區，如果容器只掛載了主機的/dev目錄，那么主機的/dev/shm目錄仍然對容器不可見。

1.3 ? ?信號量死鎖的原因分析

一個進程終止時，內核對其仍然打開著的所有有名信號量自動執行關閉操作，不論該進程是自愿終止的還是非自愿終止的，這種關閉都會發生。

然而關閉一個信號量并沒有將它從系統中刪除。也就是說，即使當前沒有進程打開著某個信號量，它的值仍然保持。另外，當持有信號量的進程中止時，該信號量的值也不改變。

如圖1所示，在典型的持有鎖期間進程終止現象的時序中，進程2將一直阻塞。若semwait附帶超時參數，將因為超時而返回失敗。即使不考慮進程2，當進程1被守護進程重啟運行的時候，仍然會導致死鎖。

當進程間共享一個信號量時，持有該信號量的進程在持有期間終止，無法讓系統自動釋放持有的鎖。多線程間也是如此，一個線程在持有某個信號量時終止，起因可能是被動（被另外一個線程取消）或主動（調用pthread_exit）。合理的程序設計，應該在線程主動退出或被動取消時，調用自定義的清理程序。但對于一個線程來說，致命的條件通常還會導致整個進程終止。比如線程執行了一個無效指針的訪問，從而引發了SIGSEGV信號，那么一旦該信號未被捕獲，整個進程就被它終止，從而導致死鎖。所以需要使用其他能在進程終止時自動釋放鎖的IPC方式，來代替POSIX信號量。

2 信號量死鎖解決方案

需求：

（1）無須強制指定容器共享宿主機的目錄、文件，或指定特殊參數;

（2）使用的同步方法必須具有進程退出時內核自動清理鎖的特性。

通過線程鎖與進程鎖組合的方式，可實現多進程和多線程下都適用的信號量，以滿足上述需求。

2.1 ? ?線程鎖

線程鎖通過一個互斥鎖+條件變量實現?；コ怄i（類型為pthread_mutex_t）用于保護代碼臨界區，從而保證任何時刻只有一個線程在臨界區內執行。當一個線程獲得某個互斥鎖后，需要等待某個條件變為真，也就是該線程可以等待在某個條件變量（類型為pthread_cond_t）上。該條件變量由另外某個線程向它發送信號，通常以廣播方式（pthread_cond_broadcast）喚醒所有等待狀態的線程。

2.2 ? ?進程鎖

利用文件鎖（即記錄上鎖record locking）可以有多個讀出鎖，但只能有一個寫入鎖的特征，僅使用整個文件范圍的寫鎖，來構造一個進程鎖。并且該類型鎖具備進程終止時由內核完成已有鎖清理工作的特征。常用方式為fcntl函數，和一個文件描述符綁定，因此對于容器和宿主機共享文件鎖，可以自由適當地指定文件位置。

線程鎖的加解鎖過程如圖2所示。

2.3 ? ?線程鎖與進程鎖組合

通過把進程鎖當作線程鎖臨界保護區對象，達到多線程在同一時刻只能有一個線程獲取進程鎖的目的，而進程鎖本身又保證了多進程對臨界區的保護?？紤]到延時場景，加鎖流程如圖3所示。

3 結語

本文分析了能源控制器信號量死鎖的原因，針對該問題及原因分析，提出了通過線程鎖與進程鎖組合的解決方案，不僅可以滿足能源控制器的開發需求，解決液晶顯示菜單無序切換等問題，還能在其他平臺同步使用該方案，降低信號量死鎖的可能性。

[參考文獻]

[1] 何鑫，杜杰，尹璐.用電信息采集系統在配網運維管理中的應用[J].電子產品世界，2019，26（3）：49-52.

[2] 秦桂云.操作系統中的死鎖問題[J].中國新技術新產品，2019（16）：23-24.

收稿日期：2021-09-01

作者簡介：張晨宏（1995—），男，浙江臺州人，碩士，軟件開發助理工程師，研究方向：電力智能采集系統。