The Linux Programming Interface

File Locking 1135

if (fcntl(fd, F_GETLK, &fl) == -1)

return -1;

return (fl.l_type == F_UNLCK)? 0 : fl.l_pid;

}

––––––––––––––––––––––––––––––––––––––––––––– filelock/region_locking.c

55.3.4 Lock Limits and Performance

SUSv3 allows an implementation to place fixed, system-wide upper limits on the

number of record locks that can be acquired. When this limit is reached, fcntl() fails

with the error ENOLCK. Linux doesn’t set a fixed upper limit on the number of record

locks that may be acquired; we are merely limited by availability of memory. (Many

other UNIX implementations are similar.)

How quickly can record locks be acquired and released? There is no fixed

answer to this question, since the speed of these operations is a function of the kernel

data structure used to maintain record locks and the location of a particular lock

within that data structure. We look at this structure in a moment, but first we con-

sider some requirements that influence its design:

z The kernel needs to be able to merge a new lock with any existing locks (held

by the same process) of the same mode that may lie on either side of the new lock.

z A new lock may completely replace one or more existing locks held by the call-

ing process. The kernel needs to be able to easily locate all of these locks.

z When creating a new lock with a different mode in the middle of an existing

lock, the job of splitting the existing lock (Figure 55-3) should be simple.

The kernel data structure used to maintain information about locks is designed to

satisfy these requirements. Each open file has an associated linked list of locks held

against that file. Locks within the list are ordered, first by process ID, and then by

starting offset. An example of such a list is shown in Figure 55-6.

The kernel also maintains flock() locks and file leases in the linked list of locks

associated with an open file. (We briefly describe file leases when discussing

the /proc/locks file in Section 55.5.) However, these types of locks are typically

far fewer in number and therefore less likely to impact performance, so we

ignore them in our discussion.

Figure 55-6: Example of a record lock list for a single file

461

100

10

RD

461

300

30

WR

871

100

10

RD

871

500

40

WR

871

2400

0

RD

1961

50

100

RD

1961

1000

100

WR

1961

4000

100

RD

1961

2000

10

WR

l_pid

l_start

l_len

l_type

l_next

Key