關(guān)注、星標(biāo)公眾號(hào)，直達(dá)精彩內(nèi)容

來(lái)源：網(wǎng)絡(luò)素材?| ZeroMing222

嵌入并發(fā)，意味著多線程或者多任務(wù)，基本上都是使用了系統(tǒng)，linux系統(tǒng)或RTOS系統(tǒng)之類的實(shí)現(xiàn)。RTOS系統(tǒng)里任務(wù)的調(diào)度主要有搶占式和時(shí)間片調(diào)度兩種，具體的區(qū)別這里就不詳細(xì)說明了。此篇章包含了并發(fā)的一些術(shù)語(yǔ)，如并發(fā)性，臨界性，資源，死鎖等的概念。最好是詳細(xì)閱讀RTOS系統(tǒng)的書籍。

聲明：文章基于《C嵌入式編程設(shè)計(jì)模式》這本書，英文是Design?Patterns?for?Embedded?Systems in C。主要是做個(gè)筆記，并添加一點(diǎn)個(gè)人的理解，分享出來(lái)與各位探討。

1.?嵌入并發(fā)和資源管理的設(shè)計(jì)模式

總共有8個(gè)模式，前兩個(gè)循環(huán)執(zhí)行模式和靜態(tài)優(yōu)先級(jí)模式，提供了兩個(gè)不同的方法來(lái)調(diào)度任務(wù)或線程。接下來(lái)3個(gè)模式臨界區(qū)模式，守衛(wèi)調(diào)用模式和隊(duì)列模式，為了使解決在多任務(wù)環(huán)境下串行訪問資源的問題。匯合模式講的是多任務(wù)以不同的方式進(jìn)行同步。最后兩個(gè)模式是關(guān)注預(yù)防死鎖問題。希望下面的模式能夠各位一點(diǎn)啟發(fā)。

1.1 循環(huán)執(zhí)行模式

循環(huán)模式有非常簡(jiǎn)單的方式調(diào)用多個(gè)任務(wù)的特點(diǎn)，允許所有的任務(wù)有同等機(jī)會(huì)運(yùn)行，但是不能及時(shí)響應(yīng)緊急事件。一般在資源少的系統(tǒng)里面使用，避免了RTOS的開銷，也不需要復(fù)雜的任務(wù)調(diào)度。簡(jiǎn)單就是最大的優(yōu)點(diǎn)。

1.1.1 模式結(jié)構(gòu)

CyclicExecutive有一個(gè)controlLoop()函數(shù)，可以反復(fù)調(diào)用每個(gè)任務(wù)的run操作。也需要等待任務(wù)的結(jié)束再調(diào)用下一個(gè)任務(wù)。

1.1.2 角色

1.1.2.1 抽象任務(wù)（AbstractCEThread）

通過聲明run()函數(shù)為線程提供接口。它是用來(lái)循環(huán)執(zhí)行的任務(wù)函數(shù)。

1.1.2.2 循環(huán)控制（CyclicExecutive）

這個(gè)類用于循環(huán)執(zhí)行每個(gè)任務(wù)。此外也有全局棧和任務(wù)本身需要的靜態(tài)數(shù)據(jù)。模式的一個(gè)變體是時(shí)間觸發(fā)循環(huán)執(zhí)行，在這個(gè)變體中，CyclicExecutive設(shè)置使用CycleTimer來(lái)開啟每個(gè)周期。也就是使用這個(gè)變體可以在周期類執(zhí)行每個(gè)函數(shù)。

1.1.2.3 循環(huán)定時(shí)器（CycleTimer）

圖中有表示帶有“0，1”，這個(gè)定時(shí)器是可選的。當(dāng)定時(shí)器時(shí)間到時(shí)，可以調(diào)用中斷或者返回TRUE給hasElapsed()函數(shù)。CyclicExecutive將調(diào)用start()為下一個(gè)周期開始計(jì)時(shí)。

1.1.2.4 具體任務(wù)實(shí)現(xiàn)（ConcreteCEThread）

每個(gè)ConcreteCEThread都有自己的run()函數(shù)，用于具體的任務(wù)實(shí)現(xiàn)。

1.1.3 效果

如前所述，該模式優(yōu)點(diǎn)在于簡(jiǎn)單，一方面很難導(dǎo)致調(diào)度程序錯(cuò)誤，另一方面對(duì)緊急事件響應(yīng)不足，使得僅使用在內(nèi)存小的設(shè)備。還有缺點(diǎn)是，任務(wù)間的通訊會(huì)值得考慮，比如一個(gè)任務(wù)需要另一個(gè)任務(wù)的數(shù)據(jù)，那么數(shù)據(jù)只能保存在全局的內(nèi)存或共享資源中。我們盡量不要定義太多的全局變量，否則會(huì)難以管理維護(hù)，和造成內(nèi)存的浪費(fèi)。

1.1.4 實(shí)現(xiàn)

該模式的實(shí)現(xiàn)非常簡(jiǎn)單。在大多數(shù)情況下，循環(huán)執(zhí)行可能僅是應(yīng)用的main()函數(shù)中調(diào)用。

?

1.2 靜態(tài)優(yōu)先級(jí)模式

大多數(shù)的實(shí)時(shí)操作系統(tǒng)都是靜態(tài)優(yōu)先級(jí)模式。所以想要使用這個(gè)模式直接移植RTOS系統(tǒng)就好了。這里的模式復(fù)雜度和完整度是無(wú)法比得上RTOS系統(tǒng)的，不過閱讀這里也可以使你對(duì)RTOS的任務(wù)調(diào)度有所了解，因?yàn)檫@是基于這個(gè)框架的。靜態(tài)優(yōu)先級(jí)模式能夠?yàn)槿蝿?wù)劃分優(yōu)先級(jí)，能夠更好響應(yīng)高優(yōu)先級(jí)時(shí)間。

1.2.1 模式結(jié)構(gòu)

除了右下角AbstraceStaticThread，SharedResource，ConcreteStaticThread這三個(gè)類，其他一般是由RTOS實(shí)現(xiàn)。

1.2.2 角色

1.2.2.1 抽象線程（AbstraceStaticThread）

是一個(gè)抽象類，提供run()函數(shù)給調(diào)度器運(yùn)行。

1.2.2.2 具體線程（ConcreteStaticThread）

ConcreteThread作為AbstraceStaticThread具體實(shí)現(xiàn)run()函數(shù)。

1.2.2.3 互斥鎖（Mutex）

是一個(gè)互斥的信號(hào)量類，用來(lái)串行訪問SharedResource。當(dāng)一個(gè)任務(wù)調(diào)用了互斥量的lock()函數(shù)，其他任務(wù)嘗試鎖定的同一個(gè)互斥量時(shí)候，會(huì)被阻塞，直到互斥量的解鎖或超時(shí)退出。

1.2.2.4 隊(duì)列（PriorityQueue）

PriorityQueue是根據(jù)優(yōu)先級(jí)，對(duì)指向StaticTaskControlBlock的指針進(jìn)行排序，也就是說隊(duì)列里存儲(chǔ)的其實(shí)每個(gè)線程的排隊(duì)。一般在RTOS系統(tǒng)里，存在不止一個(gè)隊(duì)列，有就緒隊(duì)列，阻塞隊(duì)列等，調(diào)度器會(huì)從就緒隊(duì)列取出第一個(gè)執(zhí)行。

1.2.2.5 資源（SharedResource）

該資源可能在一個(gè)或多個(gè)線程里共享，需要保證資源的正常，在下面模式會(huì)說明資源共享的問題。

1.2.2.6 棧（Stack）

每個(gè)AbstraceStaticThread都有一個(gè)棧用于返回地址和傳遞參數(shù)。

1.2.2.7 調(diào)度器（StaticPriorityScheduler）

最簡(jiǎn)單的法則：總是運(yùn)行最高優(yōu)先級(jí)的準(zhǔn)備線程。RTOS系統(tǒng)里，任務(wù)創(chuàng)建，任務(wù)切換等都需要經(jīng)過調(diào)度器。任務(wù)創(chuàng)建成功后，會(huì)把任務(wù)按優(yōu)先級(jí)加入到就緒列表中，任務(wù)掛起就會(huì)加入到掛起列表。系統(tǒng)有個(gè)滴答時(shí)鐘中斷或其他能夠進(jìn)行任務(wù)切換，查找下一個(gè)運(yùn)行的任務(wù)可以有通用方法，就是從就緒列表取。另一種是硬件方法，使用處理器自帶的硬件指令來(lái)實(shí)現(xiàn)，需要硬件本身支持。

1.2.2.8 程序控制塊（StaticTaskControlBlock）

包含了它相應(yīng)的AbstraceStaticThread對(duì)象的調(diào)度信息。有線程的優(yōu)先級(jí)，默認(rèn)開始地址，目前地址，只要線程還在沒被銷毀，這個(gè)塊就會(huì)伴隨著存在。

1.2.3 效果

靜態(tài)優(yōu)先級(jí)模式能夠?qū)κ录峁┘皶r(shí)響應(yīng)，可以對(duì)CPU大程序優(yōu)化，避免單線程因等待時(shí)占用CPU這種浪費(fèi)。因RTOS系統(tǒng)的支持，線程間通訊也有很多保證，郵箱，信號(hào)量機(jī)制，避免了過多的全局變量。

1.1.4 實(shí)現(xiàn)

最好的方式是直接移植成熟的RTOS系統(tǒng)來(lái)實(shí)現(xiàn)。使用這種模式，需要對(duì)前期開發(fā)有個(gè)設(shè)計(jì)，對(duì)內(nèi)存分配，優(yōu)先級(jí)分配等因素，需要在程序開發(fā)前有個(gè)規(guī)劃，否則可能會(huì)造成后面存在各種問題。復(fù)雜度比單線程的高，所以需要你有個(gè)深入的理解，才能對(duì)RTOS系統(tǒng)運(yùn)用掌握，但是也不用害怕，RTOS始終還是中小的系統(tǒng)，有時(shí)間可以研究源碼，RTOS對(duì)指針，數(shù)據(jù)結(jié)構(gòu)的運(yùn)用非常的成熟高效。

?

1.3 臨界區(qū)模式

臨界區(qū)模式是任務(wù)協(xié)調(diào)最簡(jiǎn)單的方式。它直接禁止了任務(wù)的切換，在臨界區(qū)內(nèi)安全訪問之后，再退出臨界區(qū)。

1.3.1 模式結(jié)構(gòu)

模式結(jié)構(gòu)非常簡(jiǎn)單，在進(jìn)入臨界區(qū)后才訪問資源。調(diào)度程序不參與臨界區(qū)的開啟和結(jié)束過程，知識(shí)提供服務(wù)禁止和重啟任務(wù)切換。如果調(diào)度系統(tǒng)不提供，則臨界區(qū)能夠在硬件級(jí)別使用C的asm直接開關(guān)中斷處理。

1.3.2 角色

1.3.2.1 臨界區(qū)（CRShaaredResource）

使用這個(gè)元素來(lái)禁止任務(wù)切換，以防止任務(wù)同時(shí)訪問資源。這個(gè)例子里，受保護(hù)資源是Value屬性，相關(guān)的服務(wù)都必須使用臨界區(qū)來(lái)保護(hù)，setValue()和getValue()函數(shù)必須獨(dú)立實(shí)現(xiàn)臨界區(qū)。

1.3.2.2 任務(wù)集合（TaskWithSharedResource）

這個(gè)元素代表所有想要訪問共享資源的任務(wù)集。這些任務(wù)并不知道保護(hù)資源的方法，因?yàn)樗环庋b在共享資源內(nèi)。

1.3.3 效果

模式特點(diǎn)就是禁止調(diào)度任務(wù)的切換，更嚴(yán)格的，禁止所有的中斷。注意的是，一旦元素離開了臨界區(qū)，將重啟任務(wù)切換，另外使用了臨界區(qū)，就注定會(huì)影響到其他任務(wù)的時(shí)序，所以盡量保證臨界區(qū)的時(shí)間不要長(zhǎng)。

1.3.4 實(shí)現(xiàn)

絕大多數(shù)的RTOS系統(tǒng)直接提供函數(shù)，調(diào)用即可。

?

1.4 守衛(wèi)調(diào)用模式

守衛(wèi)調(diào)用模式提供了鎖定的機(jī)制串行訪問，可以阻止當(dāng)鎖定后來(lái)自其他線程的調(diào)用資源。在RTOS系統(tǒng)里，直白的說就是信號(hào)量。使用這個(gè)模式可能會(huì)導(dǎo)致優(yōu)先級(jí)導(dǎo)致，或死鎖的問題發(fā)生。

1.4.1 模式結(jié)構(gòu)

在模式下，多個(gè)PreemptiveTasks通過他們的函數(shù)訪問GuardeResource。當(dāng)一個(gè)線程調(diào)用一個(gè)正在鎖定的信號(hào)量時(shí)，調(diào)度服務(wù)會(huì)把該線程加入到阻塞隊(duì)列中，等待當(dāng)那個(gè)信號(hào)量釋放或超時(shí)時(shí)，解除阻塞。調(diào)度服務(wù)必須作為臨界區(qū)實(shí)現(xiàn)信號(hào)量的lock()功能，以防止可能的競(jìng)爭(zhēng)條件。

1.4.2 角色

1.4.2.1 共享資源（GuardedResource）

在這個(gè)類中使用互斥信號(hào)量來(lái)互斥訪問。在訪問資源之前，執(zhí)行與Semaphore實(shí)例關(guān)聯(lián)的lock()函數(shù)。如果Semaphore是在非鎖定狀態(tài)，則變?yōu)殒i定；如果在鎖定狀態(tài)，則Semaphore會(huì)調(diào)度復(fù)位發(fā)信號(hào)阻塞這個(gè)任務(wù)。

1.4.2.2 任務(wù)（PreemptiveTask）

訪問共享資源的任務(wù)。

1.4.2.3 互斥信號(hào)量（Semaphore）

它串行訪問GuardedResource。lock()函數(shù)是用于訪問資源之前，release()函數(shù)是訪問資源后，調(diào)用釋放信號(hào)量。

1.4.3 效果

該模式提供及時(shí)訪問資源，并同時(shí)阻止多個(gè)能夠?qū)е聰?shù)據(jù)損壞和系統(tǒng)錯(cuò)誤行為的同時(shí)訪問。如果資源沒有上鎖，那么訪問資源并不會(huì)遭受到延遲。

1.4.4 實(shí)現(xiàn)

通過使用RTOS提供的信號(hào)量函數(shù)。一般都會(huì)提供創(chuàng)建信號(hào)量，摧毀信號(hào)量，上鎖，解鎖的接口。

?

1.5 隊(duì)列模式

隊(duì)列模式是任務(wù)異步通訊常見的實(shí)現(xiàn)。它提供了在任務(wù)間的通訊方式。發(fā)送者將消息隊(duì)列Cyrus隊(duì)列中，一段時(shí)間過后，接受者從隊(duì)列取出消息。它也可以實(shí)現(xiàn)了串行訪問共享資源，把訪問消息排隊(duì)，并且在稍后處理，這避免了共享資源同時(shí)訪問的問題。

1.5.1 模式結(jié)構(gòu)

QUEUE_SIZE聲明決定隊(duì)列能容納最大的元素?cái)?shù)目。必須足夠大來(lái)處理最差的情況，也不要太大以免內(nèi)存的浪費(fèi)。

1.5.2 角色

1.5.2.1 消息（Message）

它可以任何東西，是簡(jiǎn)單的數(shù)據(jù)值，或發(fā)送消息的詳細(xì)數(shù)據(jù)報(bào)結(jié)構(gòu)。

1.5.2.2 消息隊(duì)列（MessageQueue）

MessageQueue是QTasks間交換的信息存儲(chǔ)。提供了getNextIndex()函數(shù)來(lái)運(yùn)行計(jì)算下一個(gè)有效的索引值。insert()函數(shù)在頭部位置將Message插入到隊(duì)列中并更新頭索引。remove()函數(shù)可以用于刪除最舊的消息。iFull()，isEmpty()兩個(gè)用來(lái)檢測(cè)隊(duì)列是否已滿，是否為空。

1.5.2.3 互斥信號(hào)量（Mutex）

是互斥信號(hào)量，如靜態(tài)優(yōu)先級(jí)模式中的描述類似。

1.5.2.4 任務(wù)（QTask）

QTask是MessageQueue的客戶，要么調(diào)用insert()插入新消息，要么調(diào)用remove()訪問最早的數(shù)據(jù)。

1.5.3 效果

當(dāng)數(shù)據(jù)在任務(wù)間傳遞，隊(duì)列模式十分好用?；コ饬靠梢源_保隊(duì)列本身不會(huì)由于同時(shí)訪問造成損壞。相比守衛(wèi)調(diào)用模式，隊(duì)列模式接收數(shù)據(jù)不是很及時(shí)。

1.5.4 實(shí)現(xiàn)

隊(duì)列的最簡(jiǎn)單實(shí)現(xiàn)是消息元素?cái)?shù)組。有簡(jiǎn)單的優(yōu)點(diǎn)，也會(huì)有靈活性不足，占用空間固定等缺陷。更多是使用鏈表的方式來(lái)實(shí)現(xiàn)隊(duì)列。MessageQueue還可以添加多個(gè)緩沖區(qū)，每個(gè)優(yōu)先級(jí)一個(gè)隊(duì)列，這樣實(shí)現(xiàn)優(yōu)先級(jí)策略，或者基于消息優(yōu)先級(jí)，通過插入元素隊(duì)列中實(shí)現(xiàn)。在復(fù)雜的系統(tǒng)中，預(yù)測(cè)最佳隊(duì)列大小是不可行的，如果使用數(shù)組實(shí)現(xiàn)隊(duì)列的方式，會(huì)存在超出容量的問題。在這種情況下，可以額外使用一個(gè)緩沖隊(duì)列在作為臨時(shí)存儲(chǔ)。

?

1.6 匯合模式

任務(wù)必須以不同的方式同步。發(fā)生同步可能是共享單一資源，或者等待信號(hào)量等造成，這些隊(duì)列模式和守衛(wèi)調(diào)用模式都能夠?qū)崿F(xiàn)。但是如果同步需要的條件更加復(fù)雜呢？匯合模式就是解決這個(gè)問題。當(dāng)所有的任務(wù)都滿足同步條件時(shí)，才能繼續(xù)運(yùn)行。

1.6.1 模式結(jié)構(gòu)

需要同步的線程至少2個(gè)，同時(shí)擁有唯一的Rendezvous。

1.6.2 角色

1.6.2.1 聚合（Rendezvous）

用于管理同步。它通過兩個(gè)方式：reset()函數(shù)重置同步標(biāo)準(zhǔn)為初始條件。synchronize()函數(shù)，當(dāng)任務(wù)想要同步時(shí)調(diào)用這個(gè)方法。如果不滿足標(biāo)準(zhǔn)，則任務(wù)阻塞。這個(gè)通?？梢允褂糜^察者模式或守衛(wèi)調(diào)用模式實(shí)現(xiàn)。

1.6.2.2 計(jì)數(shù)信號(hào)量（Semaphore）

這個(gè)通常是計(jì)數(shù)信號(hào)量，有創(chuàng)建，摧毀，上鎖和釋放標(biāo)準(zhǔn)鎖的接口函數(shù)。用于存儲(chǔ)當(dāng)前所有任務(wù)滿足同步條件的數(shù)量。當(dāng)?shù)扔陬A(yù)設(shè)值時(shí)，同步條件滿足。

1.6.2.3 線程（SynchronizingThread）

代表使用Rendezvous同步的每個(gè)線程。

1.6.3 效果

在這個(gè)模式中，兩個(gè)或更多的任務(wù)都同時(shí)滿足某個(gè)條件時(shí)，才能繼續(xù)運(yùn)行或調(diào)用回調(diào)函數(shù)。

1.6.4 實(shí)現(xiàn)

該模式可以通過前面的觀察者模式，或者守衛(wèi)調(diào)用模式實(shí)現(xiàn)。如果使用的是觀察者模式，則任務(wù)必須使用函數(shù)的地址注冊(cè)，當(dāng)滿足同步條件時(shí)調(diào)用。如果使用的是守衛(wèi)調(diào)用模式，則每個(gè)Rendezvous對(duì)象擁有唯一的信號(hào)量，任務(wù)想同步時(shí)調(diào)用synchronize()函數(shù)告知給Rendezvous，當(dāng)Rendezvous滿足同步條件時(shí)，釋放信號(hào)量，并且任務(wù)隨后根據(jù)通常的調(diào)度策略全部釋放運(yùn)行。

?

1.7 同時(shí)鎖定模式

首先不考慮軟件自身導(dǎo)致的錯(cuò)誤，發(fā)生死鎖需要滿足4個(gè)條件：

1. 互斥鎖資源。

2. 當(dāng)請(qǐng)求其他資源時(shí)，一些資源已經(jīng)鎖定。

3. 當(dāng)資源鎖定是允許搶斷。

4. 存在循環(huán)等待條件。

死鎖能夠通過打破這4個(gè)條件的任意一個(gè)避免。使用臨界區(qū)模式打破的是條件1和條件3。隊(duì)列模式避免了條件1的發(fā)生。

同時(shí)鎖定模式是通過破壞條件2達(dá)到避免死鎖的目的。模式以全或無(wú)的形式工作。要么所有需要的資源一次都鎖定，要么都沒有鎖定。簡(jiǎn)單來(lái)說在線程需要某個(gè)資源的時(shí)候，只有把所有的資源都一起上鎖成功，才能成功往下執(zhí)行，這樣就避免了兩個(gè)線程都在請(qǐng)求對(duì)方的資源造成的死鎖。

1.7.1 模式結(jié)構(gòu)

一般來(lái)說，MultimasteredResource是不同資源集合的任意數(shù)目的一部分，其中ResourceMaster的單獨(dú)實(shí)例管理一個(gè)這樣的集合。

1.7.2 角色

1.7.2.1 資源管理（MultimateredResource）

這個(gè)元素通過多個(gè)ResourceMasters管理，然后他有自己的互斥信號(hào)量來(lái)避免同時(shí)申請(qǐng)鎖。使用QueryMutex必須通過tryLock()函數(shù)，以便能夠通過ResourceMasters決定所有的嘗試鎖定將會(huì)是成功或者失敗。

1.7.2.2 互斥量（QueryMutex）

這個(gè)算數(shù)是一個(gè)正常的互斥信號(hào)量，與之前的不用，它提供了tryLock()函數(shù)。這個(gè)函數(shù)和lock()函數(shù)目的是一樣的，都是為了上鎖，只是tryLock()函數(shù)除此之外，如果鎖失敗，他將會(huì)返回一個(gè)錯(cuò)誤代碼，而不是阻塞當(dāng)前的線程。

1.7.2.3 客戶（ResourceClient）

這個(gè)元素是一個(gè)客戶，想要一次訪問所有資源集合來(lái)避免死鎖。它直接訪問MultimateredResource，直到成功接收到ResourceMaster上的鎖。在使用完資源后釋放。

1.7.2.4 控制鎖（ResourceMaster）

ResourceMaster控制整個(gè)資源合集的鎖。

1.7.3 效果

同時(shí)鎖定模式通過消除必要條件2，通過一次鎖定所有需要的資源或一個(gè)都不鎖防止死鎖。但是這樣會(huì)增加了其他任務(wù)執(zhí)行的延時(shí)，而且很可能發(fā)生在甚至沒有實(shí)際資源的沖突下。在資源更多，更廣泛時(shí)出現(xiàn)這種情況更明顯。此外，模式不能解決優(yōu)先級(jí)倒置問題，事實(shí)上可能更嚴(yán)重。

1.7.4 實(shí)現(xiàn)

需要保證tryLock()函數(shù)錯(cuò)做之前確保成功鎖定MultimasteredResource。

?

1.8 排序鎖定

排序鎖定是另一種確保死鎖不會(huì)發(fā)生的方法，這次是用過防止條件4發(fā)生。通過對(duì)資源排序，并且需要客戶總是按照那個(gè)指定的順序鎖定資源，這樣就不可能形成循環(huán)等待條件。

1.8.1 模式結(jié)構(gòu)

1.8.2 角色

1.8.2.1 鎖（Mutex）

與上面的模式一樣，提供兩個(gè)基本的函數(shù)lock()和release()。

1.8.2.2 資源管理（OrderedResource）

這個(gè)是模式的核心。它有resourceID屬性，是一個(gè)唯一的與每個(gè)資源關(guān)聯(lián)的ID，并且與ResourceList關(guān)聯(lián)。這個(gè)類執(zhí)行的排序鎖定規(guī)則永遠(yuǎn)是：如果資源的resourceID大于任意已鎖定資源最大的resourceID，則資源僅能被鎖定。ResourceClient首先需要調(diào)用lockDyadic()，然后添加到資源列表中，在對(duì)資源操作完成之后，調(diào)用releaseDyadic()函數(shù)。書上把這種訪問稱作為二元的，與二元不一樣的一元，差異在一元是在內(nèi)部完成上鎖，使用資源，解鎖。而二元是可以保持在鎖的狀態(tài)，等到資源使用完之后在釋放。

1.8.2.3 客戶（ResourceClient）

代表了想要調(diào)用OrderedResource服務(wù)的元素集合。對(duì)于客戶，不需要知道關(guān)于resourceID本身的任何東西。

1.8.2.4 資源列表（ResourceList）

在這個(gè)元素里，如果傳遞的resourceID大于已鎖定資源的最大一個(gè)，則addLock()返回成功。否則返回失敗。

1.8.2.5 已使用資源（ResourceReference）

這僅是一個(gè)在有序列表中包含的resourceID數(shù)組。只是保存一個(gè)最大值是不夠的，因?yàn)楹芏噘Y源可能在任何時(shí)候鎖定。

1.8.3 效果

模式通過確保所有的客戶按相同的順序鎖定資源來(lái)消除死鎖。這個(gè)模式需要在設(shè)計(jì)時(shí)做好分析來(lái)規(guī)劃好資源的排序。例如現(xiàn)在有兩個(gè)線程，都需要用到資源A，B，C，如果線程1按A，B，C的順序鎖定，線程2按C，B，A的順序鎖定，就有可能發(fā)生死鎖。因此該模式就是為了讓資源都按照規(guī)定的序列來(lái)鎖定。

1.8.4 實(shí)現(xiàn)

模式的實(shí)現(xiàn)需要給每個(gè)OrderedResource增加額外的resourceID，并且在ResourceList的邏輯中確保每個(gè)OrderedResource的resourceID大于任意當(dāng)前所的resourceID。還有，已經(jīng)上鎖的resourceID的列表必須維護(hù)，當(dāng)OrderedResource釋放時(shí)，可以適當(dāng)?shù)劓i定其他。

ResourceList最常見的實(shí)現(xiàn)是一個(gè)按照鎖定順序表示的resourceID整形數(shù)組。

???????????????? ?END ?????????????????