這幾天同事在處理RK平臺的基于mipi協(xié)議的數(shù)據(jù)時候，碰到數(shù)據(jù)透傳到usb到PC端的時候出現(xiàn)問題，因?yàn)閿?shù)據(jù)量比較大，加上是并發(fā)傳輸，所以通信上用到了生產(chǎn)者消費(fèi)者模式。

生產(chǎn)者消費(fèi)者模式，或者更貼切的說它是一種模型，不能說屬于一種設(shè)計模式。具體來講，就是一個系統(tǒng)中存在生產(chǎn)者和消費(fèi)者兩種角色，他們通過內(nèi)存緩沖區(qū)進(jìn)行通信，而如何保證并發(fā)通信，這就是程序員要思考的問題。比如說國內(nèi)的淘寶，拼多多，京東等超級流量級別的電子商務(wù)，用戶訪問瀏覽頁面的時候，圖片資源以及網(wǎng)頁內(nèi)容要在幾秒內(nèi)就刷出來，這些就是程序員工程師的智慧的結(jié)晶，而背后很大程度上生產(chǎn)者與消費(fèi)者模式用得淋漓盡致。

生產(chǎn)者是一個或者一堆線程，消費(fèi)者也是一個或者一堆堆線程，內(nèi)存緩沖區(qū)可以使用List數(shù)組隊列，數(shù)據(jù)類型只需要定義一個簡單的類，如何處理多線程之間的協(xié)作通信。這是一門藝術(shù)性的問題，像我工作中遇到的場景，rk平臺的mipi數(shù)據(jù)總是不斷的吐露出來，而我要能隨時接納數(shù)據(jù)并且不能影響幀率，這就很考驗(yàn)人。我同事遇到就懵圈了，不會利用這個模式去解決問題，如果你還在用單線程的操作去設(shè)立數(shù)據(jù)緩存區(qū)，我覺得就有點(diǎn)愚蠢了。

在這個模型中，最關(guān)鍵就是內(nèi)存緩沖區(qū)為空的時候消費(fèi)者必須等待，而內(nèi)存緩沖區(qū)滿的時候，生產(chǎn)者必須等待。其他時候可以是個動態(tài)平衡。值得注意的是多線程對臨界區(qū)資源的操作時候必須保證在讀寫中只能存在一個線程，所以需要設(shè)計鎖的策略。

這里要提到的是用intel線程庫tbb的使用，Intel 宣布，Threading Building Blocks，Intel 眾多軟件開發(fā)工具中的一個，open source了。協(xié)議是 GPLv2。我在自己場景中是利用tbb這個庫來創(chuàng)建線程，實(shí)現(xiàn)這個生產(chǎn)者與消費(fèi)者模型。

tbb創(chuàng)建生產(chǎn)者與消費(fèi)者并發(fā)線程隊列

生產(chǎn)者隊列

消費(fèi)者隊列

實(shí)際中應(yīng)用

當(dāng)然用tbb直接來創(chuàng)建線程隊列，你可能無法去領(lǐng)悟它的精髓，所以建議你還是不要以來tbb這個庫，而自己單純的用創(chuàng)建線程的方式手撕這部分代碼。

這個模型的核心精髓是緩沖區(qū)的設(shè)立。而且你可以采用隊列，管道，sockert或者其他方式去設(shè)計分配這塊內(nèi)存緩沖區(qū)。當(dāng)數(shù)據(jù)制造快的時候，消費(fèi)者來不及處理，未處理的數(shù)據(jù)可以暫時存在緩沖區(qū)中。等生產(chǎn)者的制造速度慢下來，消費(fèi)者再慢慢處理掉。

當(dāng)然它支持并發(fā)的同時也帶來一個弊端。由于函數(shù)調(diào)用是同步的（或者叫阻塞的），在消費(fèi)者的方法沒有返回之前，生產(chǎn)者只好一直等在那邊。萬一消費(fèi)者處理數(shù)據(jù)很慢，生產(chǎn)者就會白白糟蹋大好時光。因?yàn)镽K平臺，全志813平臺，聯(lián)發(fā)科平臺這些SOC芯片處理器吐出的數(shù)據(jù)是非常快的，如果你不設(shè)立緩沖區(qū)，或者不去設(shè)計這么一塊區(qū)域去處理數(shù)據(jù)，或者基于ISP算法處理，那么你肯定會影響到幀率速度，甚至于芯片的性能無法完美的詮釋。

使用了生產(chǎn)者／消費(fèi)者模式之后，生產(chǎn)者和消費(fèi)者可以是兩個獨(dú)立的并發(fā)主體。生產(chǎn)者把制造出來的數(shù)據(jù)往緩沖區(qū)一丟，就可以再去生產(chǎn)下一個數(shù)據(jù)。基本上不用依賴消費(fèi)者的處理速度。這個模式是不在GOF提出的23種設(shè)計模式之中的，它不是基于面向?qū)ο蟮脑O(shè)計模式，而是面向過程的一個設(shè)計模式，所以經(jīng)常被廣泛用于系統(tǒng)性的架構(gòu)當(dāng)中。