使用fifo實現posix訊號量算是乙個《unix網路程式設計 卷二》中第十章的乙個高階內容，其實數中僅僅是大致的實現了posix訊號量中極為有限的一部分功能。書中重新寫了sem_open函式、sem_unlink函式、sem_close函式、sem_wait函式和sem_post函式，為什麼說使用fifo僅僅實現了posix訊號量中極為有限的一部分呢？我們需要從fifo開始分析，分析完fifo的性質之後這些問題就不難理解了。
首先fifo是乙個有名的半雙工管道，這種有名管道的實現類似於佇列，我們可以在其一端執行寫入操作，另一端進行讀取操作。雖然fifo是unix系統中可以看得到的檔案，但是要清楚向fifo中讀寫資料並不需要經過磁碟io，實際上資料仍然是寫到記憶體中的。我們可以猜測一下fifo的實現，既然ipc的乙個設計要求就是高效能，而且fifo是伴隨程序持續的，那麼為什麼不把其對映到內中呢？在這裡我們遇到了第乙個問題，就是fifo的持續性的問題，可知當最後乙個程序（執行緒）關閉了fifo時，fifo中的資料將會被丟棄。想一想posix訊號量，訊號量是乙個（至少）伴隨核心持續的一種ipc。書中給出的思路是每次掛出訊號量時向fifo中寫入乙個字元，等待時從fifo總讀出乙個位元組。可以預見下面的問題，當第乙個程序呼叫了我們實現的sem函式時，對於這個程序而言是沒有什麼影響的，當這個程序結束之後，另乙個程序試圖用sem_open函式開啟訊號量時貌似也沒有什麼問題，接下來我們呼叫sem_wait函式時就會發現程序在此處阻塞，原因就是當fifo沒有程序開啟時裡面的資料會被丟棄。這個問題需要我們特別的注意，下面還有乙個問題是因為fifo自身性質導致的。
當我們實現乙個posix訊號量時要注意了，使用open函式如果不指定不阻塞的話，那麼程序或者執行緒會阻塞在open函式處，當我們不考慮實現sem_trywait時，我們需要用非阻塞的模式分別以讀和寫的模式開啟fifo，之後還需要關閉在讀描述符上的非阻塞標記。其實在sem_open函式實現的過程中要注意的東西有很多，實現的大部分難度都集中在這裡，我們不得不對不同的情況作出不同的處理，包括出錯時要關閉開啟的所有檔案描述符並釋放記憶體等。我們不能讓函式返回一段靜態記憶體，這樣是不安全的。
接下來的問題就和fifo沒有多大的關係了，乙個有關訊號量是否有效的校驗問題，當然書上給出的方法並不完美，在執行的時候很容易就導致程式的崩潰。不過這個檢查又總是要比沒有好一些吧。
FIFO 有名管道
有名管道相關的關鍵概念 管道應用的乙個重大限制是它沒有名字，因此，只能用於具有親緣關係的程序間通訊，在有名管道 named pipe或fifo 提出後，該限制得到了克服。fifo不同於管道之處在於它提供乙個路徑名與之關聯，以fifo的檔案形式存在於檔案系統中。這樣，即 使與fifo的建立程序不存在親...
21 有名管道fifo
1.特點 有名管道 在磁碟上有這樣乙個檔案，可通過命令ls l檢視字首帶p的檔案 偽檔案，在磁碟上大小永遠為0 在核心中有乙個對應的緩衝區 半雙工的通訊方式 預設阻塞 2.使用場景 沒有血緣關係的程序間通訊 3.建立方式 命令 mkfifo 管道名 函式 mkfifo 類似於mkdir 4.fifo...
linux 有名管道（FIFO）
管道的緩衝區是有限的 管道制存在於記憶體中，在管道建立時，為緩衝區分配乙個頁面大小 管道所傳送的是無格式位元組流，這就要求管道的讀出方和寫入方必須事先約定好資料的格式，比如多少位元組算作乙個訊息 或命令 或記錄 等等 多個寫程序，乙個讀程序。可以參考我之前的部落格 一旦設定了阻塞標誌，呼叫mkfif...