的POSIX specification for fcntl()狀態：當該文件的文件描述符是由處理或過程保持該文件描述符終止關閉POSIX系統清除沒有乾淨解鎖的文件鎖定的順序是什麼？
對於給定的處理的文件相關聯的所有鎖應去除。
解鎖由終止的進程原子每個文件保存的文件段鎖定的操作是什麼？換句話說，如果一個進程已經鎖定了一個文件的字節段B1..B2和B3..B4，但是在終止之前沒有解鎖這些段，當系統解鎖它們時，是段B1..B2和B3。 .B4同時解鎖之前另一個fcntl()操作鎖定一段文件可以成功嗎？如果不是原子每文件，系統解鎖這些文件段的順序是否取決於最初獲取文件段的順序？
fcntl()的規範沒有說明，但在POSIX規範中可能有一個通用規定，要求在操作之後確定性地清理操作，以便在不正常地退出或崩潰的進程之後進行清理。
有POSIX規範的section 2.9.7了部分答案，線程交互與常規文件操作，：
所有的功能chmod()，close()，fchmod()，fcntl()，fstat()，ftruncate()，lseek()，open()，read() ，readlink(),stat(),symlink()和write()在IEEE Std 1003.1-2001中規定的效應對於常規文件操作時應相互原子化。如果兩個線程分別調用其中一個函數，則每個調用都應該看到另一個調用的所有指定效果，或者不會看到其中任何一個。
所以，對於一個普通的文件，如果一個進程的線程持有文件的段鎖和與該文件相關聯，那麼close()的影響（包括刪除所有未鎖的最後一個文件描述符調用close()在由進程保存的文件上）對於另一個進程的線程對fcntl()的調用的影響是原子的，以鎖定文件的一段。
爲exit()狀態規格：
這些功能應當終止與以下後果調用進程：
所有的文件描述符，目錄流[，轉換描述符和消息目錄描述符]在調用過程中打開時應關閉。
...
據推測，打開的文件描述符被適當調用關閉彷彿到close()，但不幸的是規範不說，按文件打開的描述是「關閉」。
當涉及到異常進程終止的步驟時，2004規範似乎更加模糊。我唯一能找到的是abort()的文檔。至少在2008規範中，_Exit()的頁面上有一個標題爲Consequences of Process Termination的部分。措辭，雖然，仍然是：
- 所有的文件描述符，目錄流，轉換描述符和消息清單描述符在調用進程中打開的，應關閉。
我不認爲POSIX規範規定鎖的釋放是否是原子的，所以你應該假設它的行爲對你來說是不方便的。如果你需要他們是原子的，他們不是;如果你需要分開處理它們，它們是原子的;如果你不在乎，有些機器會以其他方式進行單向和其他機器。所以，編寫你的代碼，以便它沒關係。
我不知道如何編寫代碼來檢測問題。
在實踐中，我期望鎖會自動釋放，但標準不會說，所以你不應該假設。
你好喬納森。感謝您的回答。我結束閱讀[第2.9.7節]（http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html#tag_02_09_07），它回答了常規文件的問題，並且當一個進程不正確地關閉了一個關聯的文件描述符與一個文件。但是，似乎有[措辭] [問題]（http://stackoverflow.com/questions/7622279/what-is-the-order-in-which-a-posix-system-clears-the-filelocks -that-were-not-unl/7623578＃7623578）進程終止的影響。 –
即使規範要求某些行爲，但我認爲我會按照您的建議進行其他假設，因爲POSIX系統可能會出現問題，導致它不符合要求。 –
出於好奇，你爲什麼在意？ （創建一個取決於鎖釋放順序的情況需要一些努力...或者我想。） – Nemo
@Nemo：我解壓 - 至少我認爲我做了 - SQLite的文件鎖定算法，以便我可以實現文件鎖定 - 基於事務的文件內容交易。這些算法通過三段鎖實現，有時其中兩個同時鎖定。我的版本和SQLite的一個區別是，我等待文件鎖定，而他們選擇重試一定次數，在嘗試之間休眠。在我看來，他們不會阻止鎖，因爲他們想要與Win98兼容，但我試圖確定是否有其他原因。 –