Linux进程间通信中的文件和文件锁Word文档下载推荐.docx
《Linux进程间通信中的文件和文件锁Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《Linux进程间通信中的文件和文件锁Word文档下载推荐.docx（11页珍藏版）》请在冰豆网上搜索。
#include<
unistd.h>
stdlib.h>
stdio.h>
errno.h>
fcntl.h>
string.h>
sys/file.h>
wait.h>
#defineCOUNT100
#defineNUM64
#defineFILEPATH"
/tmp/count"
intdo_child（constchar*path）
{
/*这个函数是每个子进程要做的事情
每个子进程都会按照这个步骤进行操作：
1.打开FILEPATH路径的文件
2.读出文件中的当前数字
3.将字符串转成整数
4.整数自增加1
5.将证书转成字符串
6.lseek调整文件当前的偏移量到文件头
7.将字符串写会文件
当多个进程同时执行这个过程的时候，就会出现racing：
竞争条件，
多个进程可能同时从文件独到同一个数字，并且分别对同一个数字加1并写回，
导致多次写回的结果并不是我们最终想要的累积结果。
*/
intfd;
intret,count;
charbuf[NUM];
fd=open（path,O_RDWR）;
if（fd<
0）{
perror（"
open（）"
）;
exit
（1）;
}
/**/
ret=read（fd,buf,NUM）;
if（ret<
read（）"
buf[ret]='
\0'
;
count=atoi（buf）;
++count;
sprintf（buf,"
%d"
count）;
lseek（fd,0,SEEK_SET）;
ret=write（fd,buf,strlen（buf））;
close（fd）;
exit（0）;
}
intmain（）
pid_tpid;
intcount;
for（count=0;
count<
COUNT;
count++）{
pid=fork（）;
if（pid<
fork（）"
if（pid==0）{
do_child（FILEPATH）;
wait（NULL）;
这个程序做后执行的效果如下：
[zorro@zorrozou-pc0process]$makeracing
ccracing.c-oracing
[zorro@zorrozou-pc0process]$echo0>
/tmp/count
[zorro@zorrozou-pc0process]$./racing
[zorro@zorrozou-pc0process]$cat/tmp/count
71[zorro@zorrozou-pc0process]$
61[zorro@zorrozou-pc0process]$
64[zorro@zorrozou-pc0process]$
我们执行了三次这个程序，每次结果都不太一样，第一次是71，第二次是61，第三次是64，全都没有得到预期结果，这就是竞争条件（racing）引入的问题。
仔细分析这个进程我们可以发现这个竞争条件是如何发生的：
最开始文件内容是0，假设此时同时打开了3个进程，那么他们分别读文件的时候，这个过程是可能并发的，于是每个进程读到的数组可能都是0，因为他们都在别的进程没写入1之前就开始读了文件。
于是三个进程都是给0加1，然后写了个1回到文件。
其他进程以此类推，每次100个进程的执行顺序可能不一样，于是结果是每次得到的值都可能不太一样，但是一定都少于产生的实际进程个数。
于是我们把这种多个执行过程（如进程或线程）中访问同一个共享资源，而这些共享资源又有无法被多个执行过程存取的的程序片段，叫做临界区代码。
那么该如何解决这个racing的问题呢？
对于这个例子来说，可以用文件锁的方式解决这个问题。
就是说，对临界区代码进行加锁，来解决竞争条件的问题。
哪段是临界区代码？
在这个例子中，两端//之间的部分就是临界区代码。
一个正确的例子是：
...
ret=flock（fd,LOCK_EX）;
if（ret==-1）{
flock（）"
ret=flock（fd,LOCK_UN）;
我们将临界区部分代码前后都使用了flock的互斥锁，防止了临界区的racing。
这个例子虽然并没有真正达到让多个进程通过文件进行通信，解决某种协同工作问题的目的，但是足以表现出进程间通信机制的一些问题了。
当涉及到数据在多个进程间进行共享的时候，仅仅只实现数据通信或共享机制本身是不够的，还需要实现相关的同步或异步机制来控制多个进程，达到保护临界区或其他让进程可以处理同步或异步事件的能力。
我们可以认为文件锁是可以实现这样一种多进程的协调同步能力的机制，而除了文件锁以外，还有其他机制可以达到相同或者不同的功能，我们会在下文中继续详细解释。
再次，我们并不对flock这个方法本身进行功能性讲解。
这种功能性讲解大家可以很轻易的在网上或者通过别的书籍得到相关内容。
本文更加偏重的是Linux环境提供了多少种文件锁以及他们的区别是什么？
flock和lockf
从底层的实现来说，Linux的文件锁主要有两种：
flock和lockf。
需要额外对lockf说明的是，它只是fcntl系统调用的一个封装。
从使用角度讲，lockf或fcntl实现了更细粒度文件锁，即：
记录锁。
我们可以使用lockf或fcntl对文件的部分字节上锁，而flock只能对整个文件加锁。
这两种文件锁是从历史上不同的标准中起源的，flock来自BSD而lockf来自POSIX，所以lockf或fcntl实现的锁在类型上又叫做POSIX锁。
除了这个区别外，fcntl系统调用还可以支持强制锁（Mandatorylocking）。
强制锁的概念是传统UNIX为了强制应用程序遵守锁规则而引入的一个概念，与之对应的概念就是建议锁（Advisorylocking）。
我们日常使用的基本都是建议锁，它并不强制生效。
这里的不强制生效的意思是，如果某一个进程对一个文件持有一把锁之后，其他进程仍然可以直接对文件进行各种操作的，比如open、read、write。
只有当多个进程在操作文件前都去检查和对相关锁进行锁操作的时候，文件锁的规则才会生效。
这就是一般建议锁的行为。
而强制性锁试图实现一套内核级的锁操作。
当有进程对某个文件上锁之后，其他进程即使不在操作文件之前检查锁，也会在open、read或write等文件操作时发生错误。
内核将对有锁的文件在任何情况下的锁规则都生效，这就是强制锁的行为。
由此可以理解，如果内核想要支持强制锁，将需要在内核实现open、read、write等系统调用内部进行支持。
从应用的角度来说，Linux内核虽然号称具备了强制锁的能力，但其对强制性锁的实现是不可靠的，建议大家还是不要在Linux下使用强制锁。
事实上，在我目前手头正在使用的Linux环境上，一个系统在mount-omand分区的时候报错（archlinuxkernel4.5），而另一个系统虽然可以以强制锁方式mount上分区，但是功能实现却不完整，主要表现在只有在加锁后产生的子进程中open才会报错，如果直接write是没问题的，而且其他进程无论open还是read、write都没问题（Centos7kernel3.10）。
鉴于此，我们就不在此介绍如何在Linux环境中打开所谓的强制锁支持了。
我们只需知道，在Linux环境下的应用程序，flock和lockf在是锁类型方面没有本质差别，他们都是建议锁，而非强制锁。
flock和lockf另外一个差别是它们实现锁的方式不同。
这在应用的时候表现在flock的语义是针对文件的锁，而lockf是针对文件描述符（fd）的锁。
我们用一个例子来观察这个区别：
[zorro@zorrozou-pc0locktest]$catflock.c
sys/types.h>
sys/stat.h>
#definePATH"
/tmp/lock"
fd=open（PATH,O_RDWR|O_CREAT|O_TRUNC,0644）;
if（flock（fd,LOCK_EX）<
printf（"
%d:
locked!
\n"
getpid（））;
/*
*/
unlink（PATH）;
上面代码是一个flock的例子，其作用也很简单：
1.打开/tmp/lock文件。
2.使用flock对其加互斥锁。
3.打印“PID：
locked！
”表示加锁成功。
4.打开一个子进程，在子进程中使用flock对同一个文件加互斥锁。
5.子进程打印“PID：
如果没加锁成功子进程会推出，不显示相关内容。
6.父进程回收子进程并推出。
这个程序直接编译执行的结果是：
[zorro@zorrozou-pc0locktest]$./flock
23279:
23280:
父子进程都加锁成功了。
这个结果似乎并不符合我们对文件加锁的本意。
按照我们对互斥锁的理解，子进程对父进程已经加锁过的文件应该加锁失败才对。
我们可以稍微修改一下上面程序让它达到预期效果，将子进程代码段中的注释取消掉重新编译即可：
将这段代码上下的//删除重新编译。
之后执行的效果如下：
[zorro@zorrozou-pc0locktest]$makeflock
ccflock.c-oflock
23437:
此时子进程flock的时候会阻塞，让进程的执行一直停在这。
这才是我们使用文件锁之后预期该有的效果。
而相同的程序使用lockf却不会这样。
这个原因在于flock和lockf的语义是不同的。
使用lockf或fcntl的锁，在实现上关联到文件结构体，这样的实现导致锁不会在fork之后被子进程继承。
而flock在实现上关联到的是文件描述符，这就意味着如果我们在进程中复制了一个文件描述符，那么使用flock对这个描述符加的锁也会在新复制出的描述符中继续引用。
在进程fork的时候，新产生的子进程的描述符也是从父进程继承（复制）来的。
在子进程刚开始执行的时候，父子进程的描述符关系实际上跟在一个进程中使用dup复制文件描述符的状态一样（参见《UNIX环境高级编程》8.3节的文件共享部分）。
这就可能造成上述例子的情况，通过fork产生的多个进程，因为子进程的文件描述符是复制的父进程的文件描述符，所以导致父子进程同时持有对同一个文件的互斥锁，导致第一个例子中的子进程仍然可以加锁成功。
这个文件共享的现象在子进程使用open重新打开文件之后就不再存在了，所以重新对同一文件open之后，子进程再使用flock进行加锁的时候会阻塞。
另外要注意：
除非文件描述符被标记了close-on-exec标记，flock锁和lockf锁都可以穿越exec，在当前进程变成另一个执行镜像之后仍然保留。
上面的例子中只演示了fork所产生的文件共享对flock互斥锁的影响，同样原因也会导致dup或dup2所产生的文件描述符对flock在一个进程内产生相同的影响。
dup造成的锁问题一般只有在多线程情况下才会产生影响，所以应该避免在多线程场景下使用flock对文件加锁，而lockf/fcntl则没有这个问题。
升级会员 