阻塞与非阻塞I/O

发布时间:2014-10-23 23:23:14
来源:分享查询网

还记得上篇 我们讲到的是linux中并发控制访问的手段有哪些????原子、信号量、自旋锁、互斥体。这是为了保护临界区的资源,是多个进程对共享资源的并发访问的一种处理手段。但是,在驱动程序中,我们常常为了支持用户空间对设备的灵活访问,引入了阻塞与非阻塞I/O两种不同模式。    阻塞操作是指在执行设备操作时若不能获得资源则挂起进程,直到满足可操作的条件后再进行操作。 因为阻塞的进程会进入休眠状态,因此,必须确保有一个地方能够唤醒休眠的进程。唤醒进程的地方最大可能发生在中断里面,因为硬件资源获得的同时往往伴随着一个中断。   注意:驱动程序需要提供阻塞(等待队列,中断)和非阻塞方式(轮询,异步通知)访问设备。   休眠(被阻塞)的进程处于一个特殊的不可执行状态。这点非常重要,否则,没有这种特殊状态的话,调度程序就可能选出一个本不愿意被执行的进程,更糟糕的是,休眠就必须以轮询的方式实现了。进程休眠有各种原因,但肯定都是为了等待一些事件。事件可能是一段时间、从文件I/O读更多数据,或者是某个硬件事件。一个进程还有可能在尝试获得一个已经占用的内核信号量时被迫进入休眠。休眠的一个常见原因就是文件I/O -- 如进程对一个文件执行了read()操作,而这需要从磁盘里读取。还有,进程在获取键盘输入的时候也需要等待。无论哪种情况,内核的操作都相同:进程把它自己标记成休眠状态,把自己从可执行队列移出,放入等待队列,然后调用schedule()选择和执行一个其他进程。唤醒的进程刚好相反:进程被设置为可执行状态,然后再从等待队列中移到可执行队列。   休眠有两种相关的进程状态:TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE。它们的惟一区别是处于TASK_UNINTERRUPTIBLE状态的进程会忽略信号,而处于TASK_INTERRUPTIBLE状态的进程如果收到信号会被唤醒并处理信号(然后再次进入等待睡眠状态)。两种状态的进程位于同一个等待队列上,等待某些事件,不能够运行。   休眠通过等待队列进行处理。等待队列是由等待某些事件发生的进程组成的简单链表。内核用wake_queue_head_t来代表等待队列。等待队列可以通过DECLARE_WAITQUEUE()静态创建,也可以有init_waitqueue_head()动态创建。进程把自己放入等待队列中并设置成不可执行状态。等与等待队列相关的事件发生的时候,队列上的进程会被唤醒。为了避免产生竞争条件,休眠和唤醒的实现不能有纰漏。   等待队列   在Linux驱动程序中,可以使用等待队列来实现阻塞进程的唤醒。   进程通过执行下面几步将自己加入到一个等待队列中: 当然,首先是定义等待队列头,并初始化:    wait_queue_head_t wait;    init_waitqueue_head(&wait); 1. 调用DECLARE_WAITQUEUE()创建一个等待队列的项 |/* 'q' is the wait queue we wish to sleep on */ | |DECLARE_WAITQUEUE(wait, current); |     2. 调用add_wait_queue()把自己加入到队列中。该队列在进程等待的条件满足时唤醒它。当然我们必须在其他地方撰写相关代码,在事件发生时,对等待队列执行wake_up()操作 |-----------------------------| |add_wait_queue(q, &wait); | |-----------------------------| while (!condition) { /* condition is the event that we are waiting for */   3. 将进程的状态变更为TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE |----------------------------------------------| | /* or TASK_UNINTERRUPTIBLE */ | | __set_current_state(TASK_INTERRUPTIBLE); | |----------------------------------------------|   4. 如果状态被设置为TASK_INTERRUPTIBLE,则信号可以唤醒进程(信号和事件都可以唤醒该进程)。这就是所谓的伪唤醒(唤醒不是因为事件的发生,而是由信号唤醒的),因此检查并处理信号。 注: 信号和等待事件都可以唤醒处于TASK_INTERRUPTIBLE状态的进程,信号唤醒该进程为伪唤醒;该进程被唤醒后,如果(!condition)结果为真,则说明该进程不是由等待事件唤醒的,而是由信号唤醒的。所以该进程处理信号后将再次让出CPU控制权 |----------------------------------------------| | if (signal_pending(current)) | | /* handle signal */ | |----------------------------------------------|   5. Tests whether the condition is true. If it is, there is no need to sleep. If it is not true, the task calls schedule(). 本进程在此处交出CPU控制权,如果该进程再次被唤醒,将从while循环结尾处继续执行,因而将回到while循环的开始处while (!condition),进测等待事件是否真正发生. |----------------------------------------------| | schedule(); | |----------------------------------------------| }   6. Now that the condition is true, the task can set itself to TASK_RUNNING and remove itself from the wait queue via remove_wait_queue(). |----------------------------------------------| |set_current_state(TASK_RUNNING); | |remove_wait_queue(q, &wait); | |----------------------------------------------|   另外,在程序中必须有唤醒等待队列的机制: Wake_up_interruptible(&q);     轮询操作   轮询的概念与作用 使用非阻塞I/O的应用程序通常会使用select()和poll()系统调用查询是否可对设备进行无阻塞的访问。select()和poll()系统调用最终会引发设备驱动中的poll()函数被执行。   select()和poll()系统调用的本质一样,前者在BSD UNIX中引入,后者在System V中引入。   应用程序中的轮询编程   int select(int numfds,fd_set *readfds, fd_set *writefds, fd_set *exceptfds,struct timeval *timeout);   文件描述符集合操作:FD_ZERO(fd_set *set) FD_SET(int fd, fd_set *set) FD_CLR(int fd, fd_set *set) FD_ISSET(int fd, fd_set *set)   设备驱动中的轮询编程   unsigned int (*poll)(struct file *filp, struct poll_table *wait); void poll_wait(struct file *filp, wait_queue_head_t *queue, struct poll_table *wait);     poll()函数的典型模板:   static unsigned int xxx_poll(struct file *filp, poll_table *wait) { unsigned int mask = O; struct xxx_dev *dev - filp->private_data;//获取设备接构体指针   ..... poll_wait (filp, &dev->r_wait, wait);//加读等待队列头 poll_wait (filp, &dev->w_ait, waitl);//加写等待队列头   if(...) //可读 { mask |=POLLIN|POLLRDNORM; //标志数据可获得 }   if(...) //可写 { mask |=POLLOUT|POLLRDNORM; //标志数据可写入 } ... return mask; }           自从看到一个命令在我的手下,蹦的一下------------我就笑了

返回顶部
查看电脑版