引言

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

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

1信號量死鎖問題概述

1.1問題背景

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

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

不同的進程總是能夠訪問同一個有名信號量,只要它們在調(diào)用SemopeО時指定相同的名字。即使對于某個給定名字的SemopeО調(diào)用,在每個調(diào)用進程中可能返回不同的指針,使用該指針的信號量函數(shù)（例如SempoSt和Semwait）所引用的仍然是同一個有名信號量。

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

在使用相同名字的前提下,需要了解有名信號量保存的具體位置。跟消息隊列類似,它保存在/dev/Shm目錄中。在這個目錄中可以找到被創(chuàng)建了的、但是沒有調(diào)用SemuОl(fā)iОk的信號量。

每個Docker容器都有一個本地存儲空間,用于保存層疊的鏡像層（ImageLayer）以及掛載的容器文件系統(tǒng)。容器內(nèi)外的進程要達到信號量共用的目的,需要容器與主機共享數(shù)據(jù)。用法是使用-v選項將hoSt已經(jīng)存在的目錄或者文件掛載到容器。

通過對信號量未失效容器和信號量失效容器的掛載配置信息的比對,可以發(fā)現(xiàn)在信號量未失效容器中,容器同時掛載了主機的/dev和/dev/Shm目錄,而信號量失效容器只掛載了主機的/dev目錄。這兩個目錄在主機上是兩個不同的掛載點,文件系統(tǒng)也不同,/dev/Shm是LiОux中動態(tài)大小的一個內(nèi)存文件系統(tǒng)分區(qū),如果容器只掛載了主機的/dev目錄,那么主機的/dev/Shm目錄仍然對容器不可見。

1.3信號量死鎖的原因分析

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

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

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

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

2信號量死鎖解決方案

需求:

(1）無須強制指定容器共享宿主機的目錄、文件,或指定特殊參數(shù):

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

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

2.1線程鎖

線程鎖通過一個互斥鎖＋條件變量實現(xiàn)?；コ怄i(類型為pthread一mteut）用于保護代碼臨界區(qū),從而保證任何時刻只有一個線程在臨界區(qū)內(nèi)執(zhí)行。當一個線程獲得某個互斥鎖后,需要等待某個條件變?yōu)檎?也就是該線程可以等待在某個條件變量(類型為pthreadcondt）上。該條件變量由另外某個線程向它發(fā)送信號,通常以廣播方式(pthreadcondbroadcaSt）喚醒所有等待狀態(tài)的線程。

2.2進程鎖

利用文件鎖(即記錄上鎖record:oclkni）可以有多個讀出鎖,但只能有一個寫入鎖的特征,僅使用整個文件范圍的寫鎖,來構造一個進程鎖。并且該類型鎖具備進程終止時由內(nèi)核完成已有鎖清理工作的特征。常用方式為fcnt:函數(shù),和一個文件描述符綁定,因此對于容器和宿主機共享文件鎖,可以自由適當?shù)刂付ㄎ募恢谩?

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

2.3線程鎖與進程鎖組合

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

3結語

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