Comparison of various programming locks under Linux-file lock

• Shing
• Email: [Email protected]
• Blog: Http://blog.csdn.net/qifengzou
• Date: 2014.09.12
  
• Reprint please indicate the CSDN blog from "Chifeng"

1 Overview

A system that contains multiple threads/processes will often have multiple threads/processes at the same time reading or modifying data at the same memory address, in order to ensure the integrity of the data, The most common way is to use the lock mechanism. There are many kinds of programming locks, such as file lock, mutex, read/write lock, Semaphore, atomic lock, etc., although they all play the role of guaranteeing data integrity, but their scope, application scenario, time cost are different. in This paper, we will make a simple comparison and elaboration of the applicable scene and time cost of each lock by experiment, and provide a reference for the future working process to use which kind of lock is more suitable and tangle.

2 File Lock

In Linux systems, there are 3 ways to access file Locks: flock (), Fcntl (), LOCKF (). The two interfaces are described separately below.

2.1 flock () function

Table 1 Description of the flock () function

Description Item	Description
Header file	#include <sys/file.h>
Function prototypes	int flock (int fd, int operation)
function description	2. This function can only handle files on a single host and cannot process files on NFS. 3. This function locks and unlocks the files that the FD lock points to, as specified by operation. 4. This function can only manipulate the entire file, and cannot manipulate parts of the file. 5, this function is the proposed lock, when the process ends, the system will automatically release the lock.
Parameter description	The parameter operation has the following four conditions: Lock_sh: Establish a shared lock. Multiple processes can share a lock on the same file at the same time. LOCK_EX: establishes a mutex lock. A file has only one mutex lock at a time. Lock_un: unlocks the file lock status. LOCK_NB: When a lock cannot be established, the operation is not blocked and the result of the operation is returned immediately. 1. This option does or with Lock_sh or LOCK_EX (|) Combination. such as: Fblock (FD, LOCK_NB | LOCK_EX) or fblock (FD, LOCK_NB | LOCK_SH) 2. A single file cannot establish shared and mutex locks at the same time, and the file descriptor does not inherit this lock when using DUP () or fork (). 3, return value 0 indicates success, if there is an error returns-1, the error code is stored in errno.

The reference code for its use is as follows:

Figure 1 Flock () reference code

2.2 fcntl () function

Table 2 Description of the Fcntl () function

Description Item	Description
Header file	#include <fcntl.h>
Function prototypes	int fcntl (int fd, int cmd, .../* arg */)
Function description	Only features related to locks are described here: 1, This function conforms to POSIX standard file lock implementation, so it is portable. 2. This function can handle not only local files, but also files on NFS. The FCNTL () request is submitted to the daemon called RPC.LOCKD, which is then responsible for the dialogue with the host side LOCKD. 3. This function not only can operate the whole file, but also can manipulate some areas of this file. 4, this function can not only add the proposed lock, but also support the addition of mandatory lock.
Parameter description	1) When Cmd is F_SETLKW, block read lock or add write lock or unlock. 2) When CMD is f_setlk, non-blocking read lock or add write lock or unlock. 3) When CMD is one of the above 2 values, the third parameter of the function is: struct flock { Short L_type; /* Operation type: F_rdlck (read lock), F_wrlck (write lock), F_unlck (unlock) */ off_t L_start; /* Start offset */ Short l_whence; /* Relative Position: Seek_set (at the beginning of file), Curr_set (current position), End_set (end of file) */ off_t L_len; /* Operation Length: 0 = from start to end of file */ pid_t L_pid; /* Process ID: Do not have to be set. This value is returned when CMD is F_GETLK */ }

The lock operation interfaces implemented using FCNTL () are as follows:

Figure 2 Fcntl () non-blocking lock operation

Figure 3 fcntl () blocking lock Operation

Although the above 2 functions support read lock, write lock, Unlock and so on, but too many parameters, not very good use. To simplify the use of the interface, you can use the following macro substitution: (due to the read-write lock of the thread, FCNTL () only supports process-level locks, so its name starts with PROC_)

Figure 4 Macro definition of a lock

2.3 lockf () function

Table 2 Description of the LOCKF () function

Description Item	Description
Header file	#include <unistd.h>
Function prototypes	int lockf (int fd, int cmd, off_t len)
Function description	1, This function conforms to POSIX standard file lock implementation, so it is portable. 2, in the Linux operating system, this function is based on the FCNTL () package, in other operating systems, many are also implemented. But The relationship between LOCKF () and Fcntl () is not specified in posix.1-2001. 3, a portable program, you should avoid mixing lockf () and Fcntl () to use.
Parameter description	1. Parameter cmd: command type 1) When CMD is F_lock, a mutex is added to the specified segment of the file. Blocking 1. If all or part of the locked segment has been locked by another process (not a thread), the process will block until the segment is released; 2. If the locking end is overlapping with the lock end before the process, the lock section will be merged; 3. When the file descriptor is closed or the process exits, the lock is automatically released; 4. The child process will not inherit the lock of the parent process; 2) When CMD is F_tlock, a mutex is added to the specified segment of the file. (Non-blocking) This option is consistent with F_lock, but if all or part of the lock segment is already occupied by another process, it will not block, but immediately return an error. 3) When CMD is F_ulock, unlock the specified segment of the file. 1. This option may cause the lock segment to be split into a 2 segment plus lock segment. 2. For example: the 2nd to 9th byte of the file is locked, the 4th to 7th byte can be unlocked by this function, resulting in 2nd to 3rd and 8th to 9th ends is still in lock state. 4) When CMD is F_test, the specified segment of the test file is locked. (Non-blocking) 1. When the test section is not locked by another process, or is locked, return 0; 2. When the test segment is locked by another process, set the errno to Eagain (some systems are set to eaccess) and return-1. 2. Parameter len: Operation length 1) When Len has a positive value, the range of operations is: POS ~ pos+len-1 (Note: POS is the file's current offset) 2) When Len has a negative value, the range of operations is: Pos-len ~ pos-1 3) When Len's value is zero, the scope of the operation is: pos ~ file End (note: The end of the file refers to the current and future end of the file)

The lock operation interfaces implemented using LOCKF () are as follows:

Figure 5 LOCKF () sample code

The 3 functions Lockf (), fcntl (), Flock (), and the scope of multiple write locks are process-level, which cannot be used to guarantee the security and consistency of data in multiple threads.

Assumption: There are processes 3 processes A, B and C simultaneously grab a process-level mutex L (process A has multiple threads A1, A2 、... ）。 If process a grabs the lock L, processes B and C are no longer able to lock successfully until process a releases the lock. If a process grab lock succeeds through thread A1, then when thread A2, A3 、... When the operation of the lock L is executed again, the lock is still successful, and if the lock L is snatched by thread an, the lock L can be released by thread ax.

The effects of read and write locks implemented with the above 3 functions and the effect of mutexes are consistent across multiple threads, and are not described here.

In summary: The above 3 functions Lockf (), fcntl (), flock () implementation of the mutex , the scope of the multi-write lock is process-level, such a lock can not be used to ensure the security and consistency of data in multi-threading.

Comparison of various programming locks under Linux-file lock