有没有任何安全的方法来获得当前正在等待完成的任务数量？

问题描述：

我有一个很好的内核编程任务，涉及一种新颖的内核锁定方法，我的团队和我选择将它作为一个完成包装来实现。但是，规范要求我们返回我们的方法通知的进程数，其中涉及返回执行过程中由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()唤醒的进程数。这段代码已经取得了锁并且将进程列表唤醒，即。为了唤醒它们，为什么不让它返回醒来的进程数呢？

不complete_all只是唤醒所有进程？我根本不走进程列表，我只是调用complete_all并让它做到这一点。 – Alex 2010-10-15 19:38:34

是complete_all（）唤醒所有进程，并且这样做必须知道有多少“全部”，并且可以将它返回给您。有人可能会认为这是一种黑客攻击，但我认为这是一个合理的解决方案，并且比清单上的清单更清晰，以便清点数量。 – mpe 2010-10-18 13:35:00

答

您可能只是想更改__wake_up_common，以便返回已被唤醒的任务数量，然后修改complete_all以返回相同的数字。

玩得开心，手机朝上和朝下。

顺便说一句，一个不透明的结构将有typedef struct whatever whatever_t，像atomic_t。那些是不透明的。

Nico。