以用户的视角看资源管理器
我们早就看到用户所要的是什么东西的暗示了。用户需要的是使用标准POSIX函数的,基于文件描述符的接口。
实际上,在表面下面还是有很多事情值得关注的。
例如,用户如何连接到合适的资源管理器?在联合文件系统下会发生什么事?对于目录是如何处理的?
查找服务器
用户做的第一件事就是使用open()函数来获取文件描述符。(需要说明的是,当用户使用高级函数fopen()的话,最终也会回到这里,因为fopen()最终还是调用open()函数)
我们早就看到用户所要的是什么东西的暗示了。用户需要的是使用标准POSIX函数的,基于文件描述符的接口。
实际上,在表面下面还是有很多事情值得关注的。
例如,用户如何连接到合适的资源管理器?在联合文件系统下会发生什么事?对于目录是如何处理的?
查找服务器
用户做的第一件事就是使用open()函数来获取文件描述符。(需要说明的是,当用户使用高级函数fopen()的话,最终也会回到这里,因为fopen()最终还是调用open()函数)
我们已经谈过调度算法以及线程状态,但是我们还没有说过线程等重新调度的原因与时间。有一个常见的误解就是:重新调度的发生是没有什么原因的。这在设计阶段是一个有用的概念。但是更重要的是你要知道产生重新调度的条件。
重新调度只会由于以下几个原因才会发生:
在编程中你可能注意到你想要能够运行多个线程,并且你也想在某个限度上控制这些线程的行为。例如,在一个服务器中,你可能决定只让一个线程阻塞,等待来自客户端的一个消息。当这个线程获得了消息并开始处理这个请求的时候,你可能需要再创建一个新的线程来等待下一个请求的到来,以便在新的请求到了的时候由这个线程完成相应的处理。如此下来,过了一段时间所有的请求都被处理之后,你就会有多个线程在那里等待后续的客户端请求了。为了保护资源,你可能需要杀掉一些多余的线程。
这其实是一个常见的操作,Neutrino实时系统也提供了一个库来帮助处理这些操作。
现在需要注意的是这些线程池中的线程做了两个不同的操作:
条件变量(condition variables或condvars)与前面讲的睡眠锁(sleepon lock)非常类似。而实际上睡眠锁是在条件变量的基础上构建的,这也是为什么我们在睡眠锁的例子的解释表中有一个CONDVAR状态。它也能通过不停的调用pthread_cond_wait()函数来释放互斥体、等待以及重新获取互斥体,和pthread_sleepon_wait()函数一样。
下面我们就略过初始化的步骤,并使用条件变量来重新完成sleepon部分的那个生产者与消费者的多线程的程序。之后再讨论调用的函数。
在多线程程序中常遇到的另外一个情况就是让线程等待某件事的发生。这件事可以是任何事。它可以是设备上的数据就绪了,也可以是传送带到达了合适的位置或数据已经写入磁盘了,等等。另外还要讨论一下多个线程等待某个事件的情况。
为了实现这个功能,我们可以使用条件变量(condition variable)或是更简单的睡眠锁(sleepon lock)。
要使用睡眠锁,你需要执行几个操作。先看看要调用的函数,之后再看看你该如何使用这个锁:
近期评论