Home Accessibility Courses Diary The Mouth Forum Resources Site Map About Us Contact
 
For 2021 - online Python 3 training - see ((here)).

Our plans were to retire in summer 2020 and see the world, but Coronavirus has lead us into a lot of lockdown programming in Python 3 and PHP 7.
We can now offer tailored online training - small groups, real tutors - works really well for groups of 4 to 14 delegates. Anywhere in the world; course language English.

Please ask about private 'maintenance' training for Python 2, Tcl, Perl, PHP, Lua, etc.
File Locking

WHY DO WE NEED FILE LOCKING?

If several processes wish to READ the same data file at the same time, and no process is writing to it at the same time, it's easy - each reader can open and read the file independently of the others and with no special programming to take any account of the concurrent access.

However, if a process wishes to WRITE to a data file that's being concurrently read by another process, there's a risk that the act of writing to the file while another process is reading it will cause that reader to get corrupted / incomplete / mixed data. If two or more processes wish to write to a data file concurrently, there's a risk that the data in the file itself will get corrupted.

A FILE LOCKING scheme can be used to overcome these problems. Reader processes indicate that they are accessing the file (for reading) by requesting and obtaining a non-exclusive lock before they read. As many processes as need to may request and obtain non-exclusive locks at the same time. Writer processes will need to request and obtain an exclusive lock before they write. Non-exclusive locks will only be granted if there is NOT an exclusive lock issued at the time, and exclusive locks will only be granted if these is not any lock (exclusive or nonexclusive) issued at the time. It is important for processes to release locks once they have completed the activity for which the lock was requested.

ISSUES TO BE CONSIDERED

a) Deadlocks. If one process asks for a lock on file "a" and then for a lock on file "b", and another asks for the same two files to be locked in reverse order, then it's possible for a situation to arise in which both processes are blocked while they wait for the other

b) Blocking or non-blocking. If a process is refused a lock, what should it do? Wait until a lock is available (a blocking lock, as the process blocks), or simply raise a flag within the calling process and carry on but without the data access at that point (a non-blocking lock).

c) Ensuring that locks are released. Important, as the locks form a bottleneck and if a release is overlooked or fails, you'll be left with a jammed system. Take especial care if there's any danger of a process failing between obtaining and releasing a lock

d) Most schemes are co-operative locking schemes. In other words all the processes involved must co-operate for them to work. There's not usually anything to stop a rogue process reading or writing a file without obtaining a lock.

ALTERNATIVES

a) If the data is structured such that it can logically be held as a series of data files each of which is written by only a single process at a time, locking becomes easier. For example, in a timecard system using plain files, it's easier for the system to work with a directory of files (one per individual) that with a single file containing everyone's records

b) Using a database engine. All requests are made through the same daemon (or closely linked copies) which provides a locking facility that's usually easier to use. A database engine will also ensure against low level corruption at the time that parallel inserts are done (but it will only ensure against high level corruption if you take care when designing accesses).

FILE LOCKING IN PERL, C AND OTHER LANGUAGES USING FLOCK.

The C language flock function (which is exposed to Perl through the built in flock function in that language) allows the programmer to call for an exclusive (or non-exclusive) blocking or non-blocking lock, or to release such a lock.

If you're opening a file for read:
  1. Open the file THEN
  2. request the non-exclusive lock

If you're opening a file for write (append):
  1. Open the file THEN
  2. request the exclusive lock THEN
  3. When the lock is obtained, use seek / fseek to reposition
   to the end
and when you come to release the lock:
  1. Ensure all data is written (by closing the file or doing
   a seek) THEN
  2. Release the lock

FILE LOCKING IN TCL

There's a flock function (and a funlock function too) built into the TclX extension, which is now supplied as standard in many distributions of Tcl. It appears to be a slightly more sophisticated system which allows you to lock parts of a file as well as the file as a whole.

FILE LOCKING ACROSS LANGUAGES / APPLICATIONS

If you wish to apply file locking across a number of languages / technologies, you'll possibly need to roll your own; even if the technologies concerned both have their own locking schemes, there's a chance that they differ such that an exclusive lock under one scheme won't deny access under another.

I'm going to describe a simple setup here using a lock file, with all locks granted being exclusive. Unless you have multiple readers frequently active and severe resource issues, this slightly less powerful but simpler scheme will be all you need.

When any (reader or writer) process needs to access the file:

  a) Open a second file - a lock file of a specific name - for read/write.
  b) If the lock file already contains your process ID, proceed
  c) If the lock file already contains a different process ID, deny
  d) If the lock file is new / empty write and flush your process ID
     to it, then go back to step (a)

Although manipulating a lock file will be a lot quicker that working with a large data file, there are still possible conflicts - thus the need to check that you really have obtained a lock at the appropriate stage.


See also Advanced file handling in Perl

Please note that articles in this section of our web site were current and correct to the best of our ability when published, but by the nature of our business may go out of date quite quickly. The quoting of a price, contract term or any other information in this area of our website is NOT an offer to supply now on those terms - please check back via our main web site

Related Material

Perl - Advanced File and Directory Handling
  [839] - ()
  [975] - ()
  [1225] - ()
  [1709] - ()
  [1832] - ()
  [1861] - ()
  [2876] - ()
  [3412] - ()
  [3429] - ()

Object Orientation and General technical topics - Programming Algorithms
  [202] - ()
  [227] - ()
  [642] - ()
  [1157] - ()
  [1187] - ()
  [1391] - ()
  [1840] - ()
  [1949] - ()
  [2189] - ()
  [2259] - ()
  [2509] - ()
  [2586] - ()
  [2617] - ()
  [2894] - ()
  [2951] - ()
  [2993] - ()
  [3042] - ()
  [3072] - ()
  [3093] - ()
  [3102] - ()
  [3451] - ()
  [3620] - ()
  [3662] - ()
  [4325] - ()
  [4401] - ()
  [4402] - ()
  [4410] - ()
  [4652] - ()
  [4656] - ()
  [4707] - ()

resource index - Deployment
Solutions centre home page

You'll find shorter technical items at The Horse's Mouth and delegate's questions answered at the Opentalk forum.

At Well House Consultants, we provide training courses on subjects such as Ruby, Lua, Perl, Python, Linux, C, C++, Tcl/Tk, Tomcat, PHP and MySQL. We're asked (and answer) many questions, and answers to those which are of general interest are published in this area of our site.

You can Add a comment or ranking to this page

© WELL HOUSE CONSULTANTS LTD., 2022: Well House Manor • 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
PH: 01144 1225 708225 • FAX: 01144 1225 793803 • EMAIL: info@wellho.net • WEB: http://www.wellho.net • SKYPE: wellho

PAGE: http://www.wellho.net/solutions/general- ... cking.html • PAGE BUILT: Wed Mar 28 07:47:11 2012 • BUILD SYSTEM: wizard