File Locking: Difference between revisions
pc>Yuron No edit summary |
W81054ch [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
{{#set: Priority=2 | Summary=Protecting files from confusion.}}<!-- | {{#set: Priority=2 | Summary=Protecting files from confusion.}}<!-- | ||
-->{{#invoke:Dependencies|add|File Access,3}} | -->{{#invoke:Dependencies|add|File Access,3}} | ||
Like any other resource which may be shared, it can be important to be | Like any other resource which may be shared, it can be important to be able to protect against [[Race Conditions|race hazards]] if, for example, a file is shared amongst multiple processes. | ||
able to protect against [[ | |||
example, a file is shared amongst multiple processes. | |||
A simple way to do this is to provide a [[Locks|lock]] on each file, so | A simple way to do this is to provide a [[Locks|lock]] on each file, so that if one process ‘opens’ a file no other process can | ||
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? | ||
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…) | (See below…) | ||
A slight but useful variation is to allow a file to be opened for | 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 <em>all</em> previous reads are closed and no other write has been opened. This guarantees the integrity of the file as writing is exclusive. | ||
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 <em>all</em> 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 | (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. | ||
reading a file which is also being written to: you probably do this | So, sometimes, more flexible systems are useful. | ||
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. | |||
[[Image:file_download.png|link=|alt=File download]] | [[Image:file_download.png|link=|alt=File download]] | ||
=== Unix-like file locking === | === Unix-like file locking === | ||
Systems such as Linux <em>do not lock</em> files on opening. Instead, once | Systems such as Linux <em>do not lock</em> files on opening. Instead, once opened, a separate [[System Calls|system call]] may be used to lock a file (<code>flock()</code>) of even <em>part</em> of a file (<code>fcntl()</code>). Locks can also be: | ||
opened, a separate [[ | |||
file (<code>flock()</code>) of even <em>part</em> of a file (<code>fcntl()</code>). Locks can also | |||
be: | |||
*<strong>exclusive</strong> – everyone else keep out | *<strong>exclusive</strong> – everyone else keep out | ||
*<strong>shared</strong> – other processes may also create overlapping, shared locks<br /> (although an overlapping <em>exclusive</em> lock attempt will fail). | *<strong>shared</strong> – other processes may also create overlapping, shared locks<br /> (although an overlapping <em>exclusive</em> lock attempt will fail). | ||
These calls give the option of what to do on failure: a failure report | These calls give the option of what to do on failure: a failure report may be returned or the process can ask to [[Process_States|<strong>block</strong>]] until the lock is granted. The usual cautions regarding causing [[deadlock]] apply, of course, especially if a process is blocking whilst trying to lock. | ||
may be returned or the process can ask to [[Process_States|<strong>block</strong>]] | |||
until the lock is granted. The usual cautions regarding causing | |||
[[ | |||
blocking whilst trying to lock. | |||
Note that Unix locks apply to the <em>files</em> – not the file-names. | Note that Unix locks apply to the <em>files</em> – not the file-names. Locking a file with various [[Links|linked]] names will apply whatever names are used subsequently. | ||
Locking a file with various [[Links|linked]] names will apply whatever | |||
names are used subsequently. | |||
---- | ---- | ||
{{BookChapter|13.1.2|532-538}} | |||
{{PageGraph}} | {{PageGraph}} | ||
{{Category|Filing System}} | {{Category|Filing System}} | ||
{{Category|Deadlock}} | {{Category|Deadlock}} | ||
{{Category|User}} | {{Category|User}} |
Latest revision as of 10:03, 5 August 2019
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 |
---|