LDD3源码学习日记<四>

    日记三不小心被删了。。。哎，只能在回收站里面自己看了。这博客80%的功能还是写给自己看的，其他部分的功能应该是用来练习写作能力的，留下这一路走来的证据，两年后回过头来看看自己当初是怎么犯低级错误的。哈哈。。

第五章是并发与竞态，书上的内容讲的主要是信号量和自旋锁机制，还有completion，不过书上介绍这部分的内容不多，只用了短短的一页纸。信号量可以导致休眠，所以一般的可以用于临界保护区比较大的场合下，而自旋转锁锁住的进程会在原地打转，所以，如果临界保护区比较大的话，非常消耗系统资源。LDD3给出的源码里包含了信号量和completion，信号量是嵌在之前的代码里面的，一般而言，它总会出现在可能修改保护对象的代码前面。在使用信号量之前，首先要明确什么是需要用信号量保护的资源，
然后，我们才能用信号量保证对这些资源的互斥访问。对于scull设备来说，所有的信息都保存在scull_dev结构体中，因此，scull_dev就是我们要保护的资源。在main.c文件在有很多地方使用了信号量来保证对scull_dev的互斥访问。或者说，凡是要改变scull_dev结构休内容的地方，都必须加锁，防止竞态。

一、信号量

       信号量在使用之前必须先初始化，scull在模块初始化函数scull_init_module。中执行下面的循环完成对所有scull设备专用信号量的初始化，并且要注意，信号量必须在scull设备对系统其它部分可用前被初始化。因此，在下面的代码里，在scull_setup_cdev之前使用了iniy_MUTEX。

for (i = 0; i < scull_nr_devs; i++) {
		scull_devices[i].quantum = scull_quantum;
		scull_devices[i].qset = scull_qset;
		init_MUTEX(&scull_devices[i].sem);
		scull_setup_cdev(&scull_devices[i], i);
	}

在main.c中，涉及到信号量的函数有open和write、read函数，down_interruptible都是在一些局部变量初始化后执行的第一个动作。

if (down_interruptible(&dev->sem))
		return -ERESTARTSYS;

调用down_interruptible(&dev->sem)进行加锁，注意，要对down_interruptible的返回值进行检查，如果返回0，说明说明加锁成功了，可以开始操作受保护的资源scull_dev，反之，如果down_interruptible返回非0值，说明是在等待过程中被中断了，这时要退出并返回-ERESTARTSYS，交给系统处理。

给信号量加锁后，不管scull_write能否完成其工作，都必须释放信号量，代码如下：

out:
	up(&dev->sem);
	return retval;

二、completion

completion是一种轻量级机制，它允许一个线程告诉另一个线程某个工作已经完成。它包含在<linux/completion.h>里面。

如果有多个线程在等待同一个completion事件，complete函数只唤醒一个等待线程，而complete_all函数将唤醒所有等待线程。

等待completion使用如下函数：
void wait_for_completion(struct completion *c);
相应的，completion事件可以通过如下函数触发：
void complete(struct completion *c);
void complete_all(struct completion *c);

LDD3在misc-modules里给出了completion的演示，代码如下：

#include <linux/module.h>
#include <linux/init.h>

#include <linux/sched.h>  /* current and everything */
#include <linux/kernel.h> /* printk() */
#include <linux/fs.h>     /* everything... */
#include <linux/types.h>  /* size_t */
#include <linux/completion.h>

MODULE_LICENSE("Dual BSD/GPL");

static int complete_major = 0;

DECLARE_COMPLETION(comp);		//注册completion

ssize_t complete_read (struct file *filp, char __user *buf, size_t count, loff_t *pos)
{
	printk(KERN_DEBUG "process %i (%s) going to sleep\n",
			current->pid, current->comm);
	wait_for_completion(&comp);	//等待com完成
	printk(KERN_DEBUG "awoken %i (%s)\n", current->pid, current->comm);
	return 0; /* EOF */
}

ssize_t complete_write (struct file *filp, const char __user *buf, size_t count,
		loff_t *pos)
{
	printk(KERN_DEBUG "process %i (%s) awakening the readers...\n",
			current->pid, current->comm);
	complete(&comp);		//触发completion，唤醒在等待的com进程
	return count; /* succeed, to avoid retrial */
}


struct file_operations complete_fops = {
	.owner = THIS_MODULE,
	.read =  complete_read,
	.write = complete_write,
};


int complete_init(void)
{
	int result;

	/*
	 * Register your major, and accept a dynamic number
	 */
	result = register_chrdev(complete_major, "complete", &complete_fops);
	if (result < 0)
		return result;
	if (complete_major == 0)
		complete_major = result; /* dynamic */
	return 0;
}

void complete_cleanup(void)
{
	unregister_chrdev(complete_major, "complete");
}

module_init(complete_init);
module_exit(complete_cleanup);

在这里主要需要关注read和write函数的实现。

下面看complete_read的实现：
在打印即将进入睡眠的信息后，complete_read在调用wait_for_completion(&comp)，进入睡眠，即等待completion “comp”。”comp”是用DECLARE_COMPLETION(comp)创建的。如果等待的completion发生了，complete_read函数将再次打印已被唤醒相关信息。也就是说，任何进程读取模块设备文件，都会进入睡眠等待。
再来看complete_write的实现：
首先打印提示信息，然后在47行调用complete(&comp)触发completion事件，相应会唤醒一个在等待”comp”的进程。可以有多个进程进行读操作，这些读进程都会进入睡眠等待，当有执行写操作的进程时，只有一个等待进程会被唤醒，但是哪个进程，不能确定。

参考博客：http://blog.csdn.net/liuhaoyutz/article/details/7383653