文件锁

转自：蓝森林

fcntl文件锁有两种类型：建议性锁和强制性锁

    建议性锁是这样规定的：每个使用上锁文件的进程都要检查是否有锁存在，当然还得尊重已有的锁。内核和系统总体上都坚持不使用建议性锁，它们依靠程序员遵守这个规定。

    强制性锁是由内核执行的。当文件被上锁来进行写入操作时，在锁定该文件的进程释放该锁之前，内核会阻止任何对该文件的读或写访问，每次读或写访问都得检查锁是否存在。

    系统默认fcntl都是建议性锁，强制性锁是非POSIX标准的。如果要使用强制性锁，要使整个系统可以使用强制性锁，那么得需要重新挂载文件系统，mount使用参数 -0 mand打开强制性锁，或者关闭已加锁文件的组执行权限并且打开该文件的set-GID权限位。
    建议性锁只在cooperating processes之间才有用，对cooperating process的理解是最重要的，它指的是会影响其它进程的进程或被别的进程所影响的进程，举两个例子：（1）我们可以同时在两个窗口中运行同一个命令，对同一个文件进行操作，那么这两个进程就是cooperating processes；（2）cat file| sort，那么cat和sort产生的进程就是使用了pipe的cooperating processes。
    使用fcntl文件锁进行I/O操作必须小心：进程在开始任何I/O操作前如何去处理锁，在对文件解锁前如何完成所有的操作，是必须考虑的。如果在设置锁之前打开文件，或者读取该锁之后关闭文件，另一个进程就可能在上锁/解锁操作和打开/关闭操作之间的几分之一秒内访问该文件。当一个进程对文件加锁后，无论它是否释放所加的锁，只要文件关闭，内核都会自动释放加在文件上的建议性锁（这也是建议性锁和强制性锁的最大区别）,所以不要想设置建议性锁来达到永久不让别的进程访问文件的目的(强制性锁才可以)^_^；强制性锁则对所有进程起作用。

     fcntl使用三个参数 F_SETLK /F_SETLKW，F_UNLCK和F_GETLK,来分别要求、释放、测试record locks，record locks是对文件一部分而不是整个文件的锁，这种细致的控制使得进程更好地协作以共享文件资源。fcntl能够用于读取锁和写入锁，read lock也叫shared lock（共享锁）,因为多个cooperating process能够在文件的同一部分建立读取锁；write lock被称为exclusive lock(排斥锁)，因为任何时刻只能有一个cooperating process在文件的某部分上建立写入锁。如果cooperating processes对文件进行操作，那么它们可以同时对文件加read lock，在一个cooperating process加write lock之前，必须释放别的cooperating process加在该文件的read lock和wrtie lock，也就是说，对于文件只能有一个write lock存在，read lock和wrtie lock不能共存。

以下转载自维基百科：

File locking

From Wikipedia, the free encyclopedia

Jump to: navigation, search

<!-- start content -->

File locking is a mechanism that restricts access to a computer file by only allowing one user or process access at any specific time. The purpose of locking is to prevent the classic interceding update scenario (see race condition).

The interceding update problem may be illustrated as in the following example:

1. Process A reads a customer record from a file containing account information, including the customer's account balance and phone number.
2. Process B now reads the same record from the same file so it has its own copy.
3. Process A changes the account balance in its copy of the customer record and writes the record back to the file.
4. Process B--which still has the original stale value for the account balance in its copy of the customer record--updates the customer's phone number and writes the customer record back to the file.
5. Process B has now written its stale account balance value to the file, causing the changes made by process A to be lost.

File locking prevents this problem by enforcing the serialization of update processes to any given file. Most operating systems support the concept of record locking which means that individual records within any given file may be locked, so increasing the number of concurrent update processes.

One use of file locking is in database maintenance where it can serialize access to the entire physical file underlying a database. While this prevents any other process from accessing the file it can actually be more efficient than individually locking a large number of regions in the file by removing the overhead of achieving and releasing each lock.

Poor use of file locks, like any computer lock, can result in poor performance or deadlock.

Contents

[hide]

• 1 File locking in Microsoft Windows
• 2 File locking in UNIX
  • 2.1 Problems
  • 2.2 Linux
• 3 Lock files
• 4 Unlocker software
• 5 References

<script type="text/javascript"></script>

[edit] File locking in Microsoft Windows

Shared file access in Windows is managed by three distinct mechanisms:

1. Using share access controls that allow applications to specify whole-file access sharing for read, write or delete;
2. Using byte range locks to arbitrate read and write access to regions within a single file; and
3. By Windows file systems disallowing executing files from being opened for write or delete access.

The semantics of share access controls in Windows are inherited from the original MS-DOS system (where sharing was introduced in MS-DOS 3.3) Thus, an application must explicitly allow sharing - otherwise an application has exclusive read, write and delete access to the file (other types of access, such as those to retrieve the attributes of a file are allowed.)

For a file with shared access, applications may then use byte range locking to control access to specific regions of the file. Such byte range locks specify a region of the file (offset and length) and the type of lock (shared or exclusive). Note that the region of the file being locked is not required to have data within the file and applications sometimes exploit this ability to implement their functionality.

For applications that use the file read/write APIs in Windows, byte range locks are enforced (also referred to as mandatory locks) by the file systems that execute within Windows. For applications that use the file mapping APIs in Windows, byte range locks are not enforced (also referred to as advisory locks.) Byte range locking may also have other side-effects on the Windows system. For example, the Windows file sharing mechanism will typically disable client side caching of a file for all clients when byte range locks are used on any client to control access of the file. The client will observe slower access to the file because all read and write operations must be sent to the file server where the file is stored.

Improper error handling in an application program can lead to a situation where a file is locked (either using share access or with byte range file locking) and cannot be accessed by other applications. In this case the user may be able to restore access to the file by terminating the malfunctioning program manually. This is typically done through the Task Manager utility.

File sharing is determined by the sharing mode parameter in the CreateFile function used to open files. Files can be opened to allow sharing the file for read, write or delete access. Subsequent attempts to open the file must be compatible with all previously granted sharing access to the file. When the file is closed, the sharing access restrictions are adjusted to remove the restrictions imposed by that specific file open.

Byte range locking type is determined by the dwFlags parameter in the LockFileEx function used to lock a region of a file. The Windows API function LockFile can also be used and acquires an exclusive lock on the region of the file.

Any file that is executing on the computer system as a program (e.g., an EXE, COM, DLL, CPL or other binary program file format) is normally prevented by the file system from being opened for write or delete access, reporting a sharing violation, despite the fact that the program is not opened by any application. However, some access is still allowed. For example, a running application file can be renamed or copied (read) even when executing.

Files are accessed by applications in Windows by using file handles. These file handles can be explored with the Process Explorer utility. This utility can also be used to force-close handles without needing to terminate the application holding them.

Microsoft Windows XP and Server 2003 editions have introduced volume snapshot capability to NTFS, allowing open files to be accessed by backup software despite any exclusive locks. However, unless software is rewritten to specifically support this feature, the snapshot will be crash consistent only, while properly supported applications can assist the operating system in creating "transactionally consistent" snapshots. Other windows commercial software for accessing locked files include File Access Manager, and Open File Manager. It operates by installing its own drivers to access the files in kernel mode.

[edit] File locking in UNIX

Open files and programs are not automatically locked in UNIX. There are different kinds of file locking mechanisms available in different flavours of UNIX and many operating systems support more than one kind for compatibility. The two most common mechanisms are fcntl(2) and flock(2). Although some types of locks can be configured to be mandatory, file locks under UNIX are by default advisory. This means that cooperating processes may use locks to coordinate access to a file between themselves, but programs are also free to ignore locks and access the file in any way they choose to.

Two kinds of locks are offered: shared locks and exclusive locks. In the case of fcntl, different kinds of locks may be applied to different sections (byte ranges) of a file, or else to the whole file. Shared locks can be acquired by an unlimited number of processes at the same time, but an exclusive lock can only be acquired by one process, and cannot coexist with a shared lock. To acquire a shared lock, a process must wait until there are no processes holding any exclusive locks. To acquire an exclusive lock, a process must wait until there are no processes holding either kind of lock.

Shared locks are sometimes called "read locks" and exclusive locks are sometimes called "write locks". However, because locks on UNIX are advisory, this isn't enforced. Thus it is possible for a database to have a concept of "shared writes" vs. "exclusive writes"; for example, changing a field in place may be permitted under shared access, whereas garbage-collecting and rewriting the database may require exclusive access.

File locks are based on inode instead of file name, since UNIX allows multiple names to refer to the same file. This combination of inode usage and non-mandatory locking leads to great flexibility in accessing files from multiple or many processes. On the other hand, the cooperative locking approach can lead to problems when a process writes to a file without obeying file locks set by other processes. For this reason, some UNIX and UNIX-like operating systems support mandatory locking as well.

[edit] Problems

Both flock and fcntl have quirks which occasionally puzzle programmers from other operating systems.

Mandatory locks have no effect on the unlink function. As a result, certain programs may, effectively, circumvent mandatory locking. The authors of Advanced Programming in the UNIX Environment(Second Edition) observed that the ed editor did so (page 456).

Whether flock locks work on network filesystems, such as NFS, is implementation-dependent. On BSD systems flock calls are successful no-ops. On Linux prior to 2.6.12 flock calls on NFS files would only act locally. Kernel 2.6.12 and above implement flock calls on NFS files using POSIX byte range locks. These locks will be visible to other NFS clients that implement fcntl()/POSIX locks.^[1]

Lock upgrades and downgrades release the old lock before applying the new lock. If an application downgrades an exclusive lock to a shared lock while another application is blocked waiting for an exclusive lock, the latter application will get the exclusive lock and the first application will be locked out.

All fcntl locks associated with a file for a given process are removed when any file descriptor for that file is closed by that process, even if a lock was never requested for that file descriptor. Also, fcntl locks are not inherited by a child process. The fcntl close semantics are particularly troublesome for applications which call subroutine libraries that may access files.

[edit] Linux

Linux 2.4 and later added notification of external changes to files with dnotify mechanism (through the F_NOTIFY parameter in fcntl). This mechanism is replaced by the superior inotify, which was introduced in Linux 2.6.13. Linux also supports mandatory locking through the special "mount(8) -o mand" parameter for filesystem mounting, but this is rarely used.

[edit] Lock files

A system similar to the use of file locking is often used by shell scripts and other programs: creation of lock files, which are files whose contents are irrelevant (although often one will find the Process identifier of the holder of the lock in the file) and whose only purpose is to signal by their presence that some resource is locked. A lock file is often the best approach if the resource to be controlled is not a regular file at all, so using methods for locking files does not apply.

When using lock files, care must be taken to ensure that operations are atomic. In order to obtain a lock, the process must verify that the lock file does not exist and then create it, whilst preventing another process from creating it in the meantime. Various methods are used to achieve this, such as taking advantage of a system call for this purpose (such system calls are usually unavailable to shell scripts) or by creating the lock file under a temporary name and then attempting to move it into place.

Certain Mozilla products (such as Firefox, Thunderbird, Sunbird) use this type of file resource lock mechanism (using a temporary file named "parent.lock".)

[edit] Unlocker software

An unlocker is a utility used to determine what file a process is using if a user tried to delete it, and displays a list of processes as well as choices on what to do with the process (kill task, unlock, etc.) along with a drop-down list for file functions (delete, rename, move).

[edit] References

1. ^ "Linux NFS FAQ: D. Commonly occurring error messages". http://nfs.sourceforge.net/. 

<!-- NewPP limit report Preprocessor node count: 593/1000000 Post-expand include size: 2887/2048000 bytes Template argument size: 958/2048000 bytes Expensive parser function count: 0/500 --><!-- Saved in parser cache with key enwiki:pcache:idhash:1415812-0!1!0!default!!en!2 and timestamp 20090416233808 -->

Retrieved from "http://en.wikipedia.org/wiki/File_locking"

Categories: Computer file systems