信號燈使用SEM_UNDO的危機 我使用了semop,用到了SEM_UNDO這個選項,目的正是想像書上所說的可以讓它在進程退出時自動還原所做操作,可是問題出現了,當我調式程序運行了幾把之後,出現"No space left on device"的錯誤,而且不是出在semget(已經可以正確獲得SEMID),而是出在semop,查了下GOOGLE,大多是出在semget創建信號燈不夠的情況下,man了一把,發現是:      ENOSPC            The  limit  on  the  number  of  individual  processes            requesting an SEM_UNDO would be exceeded. 說明使用SEM_UNDO是有次數限制的,最後只能捨棄SEM_UNDO這個本以為是好東東的選項目. 信號燈使用SEM_UNDO的危機 沒有吧 我開始也覺得這個很有用 因為線程可以隨時退出 而不心關心自己是不是現在擁有信號量 看看ulimit中規定了嗎 或是因為你的調用太多原因 信號燈使用SEM_UNDO的危機 你不會在進程退出的時候自己又對信號燈做了把P/V操作吧？！ 信號燈使用SEM_UNDO的危機 ZZZZZZZZzzzzzzzzzzzz 搞不懂信號燈的API....55555 鬱悶啊 信號燈使用SEM_UNDO的危機 那使用posix信號燈也可以啊 UNIX網絡編程中有 但是我沒有書 沒法和你一起研究 自己看看吧 信號燈使用SEM_UNDO的危機 的確做過了,因為我要把臨界區的數據清為0,還做了個刪除信號燈 信號燈使用SEM_UNDO的危機 如果使用了SEM_UNDO，則在進程退出時不能顯式的做P/V操作，而必須由系統為你做，否則就等於做了兩遍！ 在多進程通過信號燈同步資源、而單個進程可能運行較長時間的情況下，不建議使用SEM_UNDO，否則運行進程將長時間佔用資源，僅當其退出後才會釋放！ 信號燈使用SEM_UNDO的危機 為什麼不用消息呢? 信號燈使用SEM_UNDO的危機 雖然操作系統對信號佔用資源作了限制,但既使是剛剛初始化的系統，這些限制也一般能夠滿足應用程式的需要了。像postgresql這樣一個大型的數據庫系統一般也不會用那麼多的信號資源，超出資源限制雖然可以通過增加內核的限制值，重編譯內核來解決，但一般都是你的程式設計上有缺陷. [ 關閉窗口 ]