The difference between fcntl (), LOCKF, flock in Linux _php tutorials

The difference between fcntl (), LOCKF, and Flock in Linux

The difference between fcntl (), LOCKF and Flock
--lvyilong316

What is the difference between these three functions, which are all about locking up a file? First flock and Fcntl are system calls, and LOCKF is a library function. LOCKF is actually a fcntl package, so the bottom-level implementation of LOCKF and Fcntl is the same, and the effect on file locking is the same. In the latter case, the Fcntl and LOCKF are put together in most cases when different points are analyzed. The following first look at the use of each function, from the way and effect of use to see the difference between the various functions.

1.flock

L Function prototypes

#include

Intflock (intfd,intoperation);//applyorremoveanadvisorylockontheopenfilespecifiedbyfd, just a suggested sexual lock.

Where FD is the file descriptor returned by the system call open, the options for operation are:

Lock_sh: Shared lock

LOCK_EX: Exclusive lock or exclusive lock

Lock_un: Unlock.

LOCK_NB: Non-blocking (used with three operations above)

With regard to the flock function, it is first important to know that the flock function can only lock the entire file, not a portion of the file, which is the first significant difference in FCNTL/LOCKF, which can lock a region of the file. Second, flock can only produce an advisory lock. We know that Linux has a forced lock (Mandatorylock) and an advisory lock (Advisorylock). The so-called forced lock, better understanding, is the door of your home that lock, the most deadly is only a key, only one process can operate. The so-called advisory lock, the essence is a protocol, you access the file before, check the lock, this time the lock is its role, if you are not so kind, regardless of 3,721, must read and write, then advise the lock does not have any effect. And to abide by the protocol, read and write the lock before the process, called the cooperation process. Again, the difference between flock and FCNTL/LOCKF is mainly in fork and DUP.

(1) The lock created by flock is associated with the File Open Table entry (structfile), not FD. This means that after copying the file fd (via fork or DUP), the lock can be manipulated by the two FD (for example, through one FD lock, another FD can release the lock), that is, the child process inherits the lock of the parent process. However, when one of the FD is closed during locking, the lock is not released (because the file structure is not freed) and the lock is released only if all the replicated FD is closed. Test the program into program one.

L Program One

 
  
  

  
   
   
#include  
 
  
   
   
#include  
 
  
   
   
#include  
 
  
   
   
#include  
 
  
   
   
int main (int argc, char * * argv)

  
   
   
{

  
   
   
int ret;

  
   
   
int fd1 = open ("./tmp.txt", O_RDWR);

  
   
   
int fd2 = DUP (FD1);

  
   
   
printf ("Fd1:%d, fd2:%d\n", FD1, FD2);

  
   
   
ret = Flock (FD1,LOCK_EX);

  
   
   
printf ("Get Lock1, ret:%d\n", ret);

  
   
   
ret = Flock (FD2,LOCK_EX);

  
   
   
printf ("Get Lock2, ret:%d\n", ret);

  
   
   
return 0;

  
   
   
}
 
  
  

Running the result, the lock on the FD1, does not affect the program through FD2 lock. For parent-child processes, refer to program two.

L Program Two

 
  
  

  
   
   
#include  
 
  
   
   
#include  
 
  
   
   
#include  
 
  
   
   
#include  
 
  
   
   
int main (int argc, char * * argv)

  
   
   
{

  
   
   
int ret;

  
   
   
int pid;

  
   
   
int fd = open ("./tmp.txt", O_RDWR);

  
   
   
if (PID = fork ()) = = 0) {

  
   
   
ret = Flock (FD,LOCK_EX);

  
   
   
printf ("Chile Get lock, FD:%d, ret:%d\n", FD, ret);

  
   
   
Sleep (10);

  
   
   
printf ("Chile exit\n");

  
   
   
Exit (0);

  
   
   
}

  
   
   
ret = Flock (FD,LOCK_EX);

  
   
   
printf ("Parent Get lock, FD:%d, ret:%d\n", FD, ret);

  
   
   
printf ("Parent exit\n");

  
   
   
return 0;

  
   
   
}
 
  
  

Running the result, the child process holds the lock and does not affect the parent process acquiring the lock through the same FD, and vice versa.

(2) Open two times the same file is opened, the resulting two FD is independent (because the underlying corresponds to two file objects), through one lock, through the other can not be unlocked, and before the previous unlock can not lock. Test procedures such as program three:

L Program Three

 
 

  
  

  
#include  
 
  
  

  
#include  
 
  
  

  
#include  
 
  
  

  
#include  
 
  
  

  
int main (int argc, char * * argv)

  
  

  
{

  
  

  
int ret;

  
  

  
int fd1 = open ("./tmp.txt", O_RDWR);

  
  

  
int fd2 = open ("./tmp.txt", O_RDWR);

  
  

  
printf ("Fd1:%d, fd2:%d\n", FD1, FD2);

  
  

  
ret = Flock (FD1,LOCK_EX);

  
  

  
printf ("Get Lock1, ret:%d\n", ret);

  
  

  
ret = Flock (FD2,LOCK_EX);

  
  

  
printf ("Get Lock2, ret:%d\n", ret);

  
  

  
return 0;

  
  

  
}
 
 

As a result, locks can no longer be acquired through FD2 after the lock is acquired through FD1.

(3) After using Exec, the state of the file lock is unchanged.

(4) Flock can no longer be used on NFS file systems, if you want to use file Locks on NFS, use FCNTL.

(5) Flock lock can be recursive, that is, through the DUP or the fork generated two fd, can be locked without generating a deadlock.

2.LOCKF and Fcntl

L Function prototypes

#include

INTLOCKF (Intfd,intcmd,off_tlen);

FD is the open file descriptor returned by open.

The value of CMD is:

F_lock: File Mutex lock, if the file is locked, it will be blocked until the lock is released.

F_tlock: Same as F_lock, but if the file has been locked, it will not block, and return an error.

F_ulock: Unlock.

F_test: If the test file is locked, return 0 if the file is not locked, or 1.

Len: The length to lock from the beginning of the current position of the file.

With function parameters, you can see that LOCKF only supports exclusive locks and does not support shared locks.

#include

#include

Intfcntl (Intfd,intcmd,.../*arg*/);

structflock{

...

shortl_type;/*typeoflock:f_rdlck,f_wrlck,f_unlck*/

shortl_whence;/*howtointerpretl_start:seek_set,seek_cur,seek_end*/

off_tl_start;/*startingoffsetforlock*/

off_tl_len;/*numberofbytestolock*/

Pid_tl_pid;/*pidofprocessblockingourlock (f_getlkonly) */

...

};

File record lock-related cmd divided into three kinds:

F_SETLK: Request a lock (read lock F_rdlck, write lock F_wrlck) or Release (F_UNLCK), but if kernel cannot grant the lock to this process (the other process has robbed the first, took the lock), not silly, etc., return error.

F_SETLKW: And F_setlk almost the same, the only difference, this fellow is a dead-minded Zhu Er, application is not, silly wait.

F_GETLK: This interface is information about acquiring locks: This interface modifies our incoming structflock.

The function parameter function can be seen FCNTL is the most powerful, it supports both shared and exclusive locks, that is, can lock the entire file, but also can lock only a portion of the file.

Here's a look at FCNTL/LOCKF features:

(1) lock can be recursive, if a process has a lock on a file interval, and then the process attempts to add a lock in the same interval, then the new lock will replace the old lock.

(2) The read lock (shared lock) file must be read open, and the write lock (exclusive lock) file must be write-open.

(3) The process cannot use the F_GETLK command to test whether it itself holds a lock on a part of the file. The F_GETLK command defines the description, which returns information indicating whether an existing lock prevents the calling process from setting its own lock. Because the f_setlk and F_SETLKW commands always replace the existing locks on the process, the calling process never blocks the lock that it holds, so the F_GETLK command never reports the locks that the calling process holds.

(4) When the process terminates, all the file locks he creates will be released, and the Doctor flock is the same.

(5) When a descriptor is closed at any time, any lock on the file that the process can refer to by this descriptor is freed (the locks are set by the process), which is different from flock. Such as:

Fd1=open (pathname,...);

LOCKF (fd1,f_lock,0);

Fd2=dup (FD1);

Close (FD2);

After close (FD2), the locks set on the Fd1 are released, and if you change the DUP to open so that the same file on another descriptor is opened, the effect is the same.

Fd1=open (pathname,...);

LOCKF (fd1,f_lock,0);

Fd2=open (pathname,...);

Close (FD2);

(6) The child process generated by fork does not inherit the lock set by the parent process, which is also different from flock.

(7) After Exec executes, the new program can inherit the lock of the original program, which is the same as flock. (If Close-on-exec is set for FD, the FD is closed before exec and the lock for the corresponding file is freed).

(8) Support mandatory Lock: Open its set group ID bit (S_ISGID) to a specific file and turn off its group execution bit (S_IXGRP), then the mandatory locking mechanism is turned on for the file. If you want to use mandatory locks in Linux, use _omand to open this mechanism when the file system is mount.

3. Relationship of two kinds of locks

So what does flock have to do with the lock on Lockf/fcntl? The answer is not affected. The test procedure is as follows:

 
  
  

  
   
   
#include  
 
  
   
   
#include  
 
  
   
   
#include  
 
  
   
   
#include  
 
  
   
   
int main (int argc, char **argv)

  
   
   
{

  
   
   
int FD, RET;

  
   
   
int pid;

  
   
   
FD = Open ("./tmp.txt", O_RDWR);

  
   
   
ret = Flock (FD, LOCK_EX);

  
   
   
printf ("Flock return ret:%d\n", ret);

  
   
   
ret = LOCKF (FD, F_lock, 0);

  
   
   
printf ("LOCKF return ret:%d\n", ret);

  
   
   
Sleep (100);

  
   
   
return 0;

  
   
   
}
 
  
  

The test results are as follows:

$./a.out

flockreturnret:0

lockfreturnret:0

Visible flock Lock, does not affect the LOCKF locking. Two outside we can get the state of the lock through the/proc/locks view process.

$psaux |grepa.out|grep-vgrep

123751188490.00.011904440pts/5s+01:090:00./a.out

$sudocat/proc/locks|grep18849

1:posixadvisorywrite1884908:02:8526740eof

2:flockadvisorywrite1884908:02:8526740eof

We can see the information on the lock below the/proc/locks: I will now describe the meaning:

1) Posixflock This more clear, is which type of lock. The flock system call produces a flock,fcntl call f_setlk,f_setlkw or LOCKF produces a POSIX type, and there are times when the type of lock generated by the two calls is different;

2) advisory indicates is to advise the lock;

3) write as the name implies, is written lock, and read lock;

4) 18849 is the process ID that holds the lock. Of course, for flock this type of lock, there is a situation where the process has exited.

5) 08:02:852674 indicates that the corresponding disk file is located on the device's main device, the secondary device number, and the file corresponding to the Inodenumber.

6) 0 represents the location of the place

7) EOF represents the end position. These two fields are useful for fcntl types, which are always 0 and EOF for flock.

http://www.bkjia.com/PHPjc/1112546.html www.bkjia.com true http://www.bkjia.com/PHPjc/1112546.html techarticle The difference between fcntl (), LOCKF, flock in Linux fcntl (), LOCKF, flock--lvyilong316 These three functions are to lock files, so what is the difference? First Floc ...

