我有一個很好的內核編程任務，涉及一種新穎的內核鎖定方法，我的團隊和我選擇將它作爲一個完成包裝來實現。但是，規範要求我們返回我們的方法通知的進程數，其中涉及返回執行過程中由complete_all喚醒的進程數。有沒有任何安全的方法來獲得當前正在等待完成的任務數量？
我們如何得到這個數字？看起來只要用內部自旋鎖鎖定完成就足夠了，計算元素的數量，然後解鎖它。這種方法是搶佔式安全的，因爲我們的功能是唯一可以訪問特定完成的功能。
那麼接下來的問題是：是結構完成不透明？如果是這樣，爲了讓我們的作業能夠在中期完成，是否可以接受，忽略這種不透明？或者，有沒有這樣做的手段沒有黑客？
嚴格說來它不是不透明的，即。它在標題中定義，但你知道這一點。
有可能筆者會喜歡它是不透明的，但是交易是關閉一個公共定義爲了讓靜態內聯來操作就可以了。這在內核代碼中很常見，因爲你更關心代碼的大小，而不是嚴格的API - 畢竟這是所有的內核代碼。
我看到：
struct completion {
unsigned int done;
wait_queue_head_t wait;
};
所以最有趣的位實際上是在wait_queue_head_t，這是struct __wait_queue_head一個typedef。
雙下劃線可能表明作者認爲它是私人的，或者他們只是認爲這會令人困惑，因爲有struct wait_queue_head和wait_queue_head_t，即。雙下劃線清楚地表明你打算使用typedef。
我覺得好像你在尋找它的錯誤的方式。你說你需要知道complete_all()喚醒的進程數。這段代碼已經取得了鎖並且將進程列表喚醒，即。爲了喚醒它們，爲什麼不讓它返回醒來的進程數呢？
您可能只是想更改__wake_up_common，以便返回已被喚醒的任務數量，然後修改complete_all以返回相同的數字。
玩得開心，手機朝上和朝下。
順便說一句，一個不透明的結構將有typedef struct whatever whatever_t，像atomic_t。那些是不透明的。
Nico。
不complete_all只是喚醒所有進程？我根本不走進程列表，我只是調用complete_all並讓它做到這一點。 – Alex 2010-10-15 19:38:34
是complete_all（）喚醒所有進程，並且這樣做必須知道有多少「全部」，並且可以將它返回給您。有人可能會認爲這是一種黑客攻擊，但我認爲這是一個合理的解決方案，並且比清單上的清單更清晰，以便清點數量。 – mpe 2010-10-18 13:35:00