LDD3之并发和竞态-completion(完毕量)的学习和验证

首先说下測试环境：

        Linux2.6.32.2

        Mini2440开发板

        一開始难以理解书上的书面语言，这里《linux中同步样例(完毕量completion)》举了一个公交车上司机和乘客的样例还不错，转过来：

       这是一个公交司机和售票员之间的线程调度，用于理解完毕量，完毕量是对信号量的一种补充。主要用于多处理器系统上发生的一种微妙竞争。

在这里两个线程间同步。仅仅有当售票员把门关了后。司机才干开动车，仅仅有当司机停车后，售票员才干开门。

假设还是不可以理解就仅仅能重复的调试程序了，如今就把书上的样例使用起来，编译出来completion.ko后进行例如以下步骤验证

# 1.插入内核模块

insmod completion.ko

# 2.查看申请的次设备号${MINOR}

cat /proc/devices | grep complete 

# 3.创建设备节点

mknod /dev/complete c ${MINOR} 0

# 4.首先开启一个终端查看内核信息输出

cat /proc/kmsg 

# 5.一个终端读,会睡眠

cat /dev/complete

# 6,还有一个终端写

echo /dev/complete

# 7.查看输出

<7>[22050.937732] process 28852 (cat) going to sleep

<7>[22093.994805] process 28866 (bash) awakening the readers…

<7>[22093.994817] awoken 28852 (cat)

以下来验证LDD3上所说的：

        注意wait_for_completion运行会一个非中断的等待。假设没有人来完毕该任务，则会产生一个不可杀的进程。

        验证：

        在执行了cat /dev/complete的时候就已经执行了wait_for_completion。并不执行敲代码，看不杀的进程是会不会存在。

 

        通过尝试确实是终止不了。

        结论：wait_for_completion等待后假设没人处理任务，那么真的会产生一个不可杀的用户进程，所以这个要小心使用。

 

        在运行第3步(最下)后。仅仅有第2步的cat被唤醒，第1个还在睡眠。

    结论：和书的一样。

        分了两种情况来測试：

 

        測试失败！和书上的不照！

 

        測试成功。

        结论：complete仅仅会唤醒一个等待线程，complete_all会唤醒全部等待线程，前提是静态创建。

        依据书上描写叙述这个是和complet_all配合使用的。那么就測试一下驱动。

 <img src="http://img.blog.csdn.net/20140626202101843?

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQva2FuZ2Vhcg==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast” alt=””>

        结论：使用INIT_COMPLETION进行又一次初始化后，完毕量能够多次使用。

        这段描写叙述不理解，实验证明一下：

 

        只是看了原型。有点眉目了，这个函数是要加入到exit_xxx函数中的。也就是当没有完毕时。是卸载不了的。可是为了卸载能够调用这个函数进行强制完毕并卸载。

检验一下，直接卸载：

 

        会像图中所看到的，提示“资源不可用！

”。

但如果在complete_cleanup中加入complete_and_exit后，相同是“资源不可用！”说明如果失败。

 

        相同如果失败。这里填写的是-1，可是应用程序退出码仍然是0.只是有一点是确实能够取代使用！

        驱动群中群主是这样说的。

        结论：因为多进程还没有掌握，这个先遗留下来。以后再来补充。

 

        结论：不能够被中断，到定时时间无人处理则自行结束。

        这个并没有在LDD3中出现。可是非常能够就是LDD3中注2中提到的可中断版本号.

<img src="http://img.blog.csdn.net/20140626202635406?

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQva2FuZ2Vhcg==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast” alt=””> 

        结论：证实能够被ctrl+c中断，即用户空间的进程能够被杀死！

 

        结论：10s后假设没有completion则自行中断。

        从源代码和实验结果上看不出和wait_for_completion_interruptible有不论什么差别。代码是前者使用的是TASK_INTERRUPTIBLE后者使用的是 TASK_KILLABLE。

        理论上：TASK_NTERRUPTIBLE 睡眠，能够被信号唤醒；TASK_KILLABLE睡眠 仅仅能被致命信号唤醒。

        只是如今没有办法差别哪些是致命信号，哪些不是！ 

        相同，从源代码和实验结果上看不出和wait_for_completion_interruptible_timeout有不论什么差别，代码是前者使用的是TASK_INTERRUPTIBLE后者使用的是 TASK_KILLABLE。

 

        其返回值始终为0。不知道怎样操作才用使其返回值为1.

        结论：全然不明确它存在的意义！

<img src="http://img.blog.csdn.net/20140626202846703?

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQva2FuZ2Vhcg==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast” alt=””> 

 

        结论：不管有无等待者，推断出来的都是有！

进程或者代码中都有把等待信息去掉都无济于事。