Unix环境高级编程（9） 高级IO

Unix环境高级编程（九） 高级IO
fcntl 记录锁
很多时候，当我们有多个进程要访问同一个文件的时候，为了防止多进程访问导致的不一致，我们就要考虑进程间的同步问题了。fcntl是一个非常强大的函数，在这里我们可以使用它来给文件的某一个部分上锁。先来看一下它的声明：

建议锁与强制锁
Linux系统上的文件锁主要分为建议锁(advisory lock)和强制锁(mandatory lock)。在Linux上使用的文件锁大部分为建议锁，而且使用强制锁的时候也要检查系统是否支持强制锁(http://www.ibm.com/developerworks/cn/linux/l-cn-filelock/index.html,这里有份代码传说可以检查是否支持强制锁)。根据查看的资料显示， OpenSuse11.1, CentOS5.3等系统不支持强制文件锁。
1. 建议锁又称协同锁。对于这种类型的锁，内核只是提供加减锁以及检测是否加锁的操作，但是不提供锁的控制与协调工作。也就是说，如果应用程序对某个文件进行操作时，没有检测是否加锁或者无视加锁而直接向文件写入数据，内核是不会加以阻拦控制的。因此，建议锁，不能阻止进程对文件的操作，而只能依赖于大家自觉的去检测是否加锁然后约束自己的行为。
2. 强制锁，是OS内核的文件锁。每个对文件操作时，例如执行open、read、write等操作时，OS内部检测该文件是否被加了强制锁，如果加锁导致这些文件操作失败。也就是内核强制应用程序来遵守游戏规则。
流（STREAM）
仅有理论而无实例只是纸上谈兵，unix的流机制是很妙的机制，但是unix流究竟是如何实现以及如何使用的呢，虽然unix流已经提出了很久很久，但是时至今日它也没有普遍被使用，出了solaris和windows等操作系统外，几乎没有什么系统在使用它，当今世上操作系统无非也就几家独大，按照不失一般性的分类，首先就是windows，然后是linux以及几家的unix，如solaris和各种bsd以及darvin，然后就是各家小诸侯了，不足挂齿，在几家大的中，独有windows和solaris吸取了unix的流思想，其余的好像都是比拼内功的结果，丝毫不在乎整体架构，只是在细节上略胜一筹，比如通读linux源码就会发现，里面有十分糟糕的算法，也有十分美妙的，显然不是一伙人所为，各个开发者都在各行其是，于是便失去了整体的美感，结果就是效率的提升，这也许就是GNU的绝美的地方吧(虽solaris10以及微软的开发框架也开源，但却是在不同license下的开源，和linux不可同日而语)。
在unix规范中，流机制只是一个可选的机制，它在用户进程和设备驱动之间提供了一条全双工通路，如下结构：
这里的处理模块有点类似于过滤器，可以有任意多个。流中流通的数据都是以消息的形式，它包含可选的控制信息以及可选择的数据信息，后两者都由strbuf结构体所示：

最后三行的值在 event 中设置无效。当函数返回时，如果有 event 中期待的事件发生，或是有异常发生，则 revent 会被设置成对应的值。
对于刚刚描述的这几个函数，当中断发生时，大部分实现都不会自动重启，即使是SA_RESTART flag已经被设置了。
异步I/O
unix 的信号机制提供了以异步形式通知某种事件已发生的方法，由BSD和 System V 提供了派生的所有系统提供了使用一个信号的异步I/O方法，该信号通知进程某个文件描述符已经发生了所关心的某个事件。
该类异步I/O的限制是，每个进程只有一个信号，无法对多个描述符进行的异步I/O进行标识。实际上，unix 规格说明书提供了一个可选择的通用异步I/O机制，这里暂不做讨论。
readv 和 writev 函数
先来看他们的声明：
int munmap(caddr_t addr, size_t len);

对 munmap 函数的调用并不会首先刷新缓存区。
和i啊游一点需要注意的是：关闭文件描述符不会自动解除映射关系。
参考文献
《Linux 文件锁学习笔记 》 http://blog.csdn.net/jiang1013nan/article/details/5721675
《unix流架构到底是个什么东西》 http://blog.csdn.net/dog250/article/details/5712160
《Linux——I/O复用》 http://blog.sina.com.cn/s/blog_7530db6f0100ovos.html