File Locking

Depends on	File Access

Like any other resource which may be shared, it can be important to be able to protect against race hazards if, for example, a file is shared amongst multiple processes.

A simple way to do this is to provide a lock on each file, so that if one process ‘opens’ a file no other process can open it until it is ‘closed’ again. Whilst simple, this is (unnecessarily) restrictive, especially if – for example – there are large files containing data which many processes need. However this locking prevents issues such as one process writing to a file which another one is currently reading. That would be undesirable, right? (See below…)

A slight but useful variation is to allow a file to be opened for reading by a process, even if it is already open for reading by another process; having multiple read operations is harmless because they cannot interfere with each other. However opening the file for writing may only be possible if all previous reads are closed and no other write has been opened. This guarantees the integrity of the file as writing is exclusive.

(From above …) There are cases where you might want processes reading a file which is also being written to: you probably do this regularly if you view an on-line video in that you probably start to watch before the download is complete. So, sometimes, more flexible systems are useful.

Unix-like file locking

Systems such as Linux do not lock files on opening. Instead, once opened, a separate system call may be used to lock a file (flock()) of even part of a file (fcntl()). Locks can also be:

• exclusive – everyone else keep out
• shared – other processes may also create overlapping, shared locks
  (although an overlapping exclusive lock attempt will fail).

These calls give the option of what to do on failure: a failure report may be returned or the process can ask to block until the lock is granted. The usual cautions regarding causing deadlock apply, of course, especially if a process is blocking whilst trying to lock.

Note that Unix locks apply to the files – not the file-names. Locking a file with various linked names will apply whatever names are used subsequently.

---

Also refer to:	Operating System Concepts, 10th Edition: Chapter 13.1.2, pages 532-538

Context Dependencies Dependants

Max. number:

Max. distance:

Next

Articles on Filing System

"Everything is a File" • FAT • File Access • File Attributes • File Descriptor • File Locking • File Permissions • File Systems • File Types • Files • Filing System • Filing System Implementation • Fragmentation • I-nodes • Journalling File System • Links • Network File System (NFS) • Resources

Articles on Deadlock

Atomicity • Deadlock • File Locking • Locks • Multi Threading • Multiprocessors • Mutual exclusion • Operation Ordering • Race Conditions • Reentrancy • Semaphores • Starvation • Threads

Articles on User

"Everything is a File" • Application Binary Interface (ABI) • Arrays • Boot • Buffer Overflow • Containers • Daemons • Disk Partition • Dynamic Memory Allocation • Emulator traps • Environment Variables • Errors • Exceptions • File Attributes • File Locking • File Permissions • Introduction to Operating Systems • Journalling File System • Links • Locks • Man(ual pages in Unix) • Memory Mapped Files • Monitoring • Network File System (NFS) • PATH • Pipes • Pointers • Relocatable Code • Reset • SETUID • Shell • Sockets • Spooling and Buffering • Streams • Structures • Superuser • System Calls • Unix Signals • User • Using Peripherals