RU2577200C1 - Method of synchronising access to shared resources of computer system under control of posix-compatible os and detecting and eliminating deadlocks using lock files - Google Patents

Abstract

FIELD: information technologies.

SUBSTANCE: invention relates to a method of detecting and eliminating deadlocks using lock files. Associating the shared resource with locking file. Cause system call for atomic exclusive creation and opening of the temporary file with a unique name in the same file system. Carry out system call for creating a hard link with the name of lock file to temporary file. If the system call for creating a hard link is successful, the removed hard link to the temporary file is removed and the current process operations with shared resource is ensured. If the current process does not exist in the system, then the elimination of deadlock is carried out by performing the following steps: remove from the existing lock file previous data on non-existent process; enter data on the current process into the existing lock file. Remove file lock of recording form the existing lock file. Ensure implementation of operations with shared resource by the current process. Remove existing lock file.

EFFECT: technical result consists in improving reliability of detecting and eliminating deadlocks.

1 cl

Description

FIELD OF THE INVENTION

The present invention relates to computer technology and, in particular, to ensure synchronization of access to shared resources of the computing system and the detection and elimination of hanging locks using lock files.

State of the art

Many modern computing systems have resources (files, databases, areas of RAM, etc.) that are accessed for parallel processes. To ensure correct access, various access synchronization methods are used. When synchronization is provided, exclusive access is granted to only one process, and the resource itself is blocked for writing and / or reading for other processes. Blocking can be carried out by different methods, however, there may be situations when the resource is blocked by several processes at the same time, and none of them can neither remove the lock, nor perform the necessary operations with the shared resource.

This condition is usually called a deadlock, determine its presence and then eliminate it using various mechanisms.

So, there is a method of synchronizing access to shared resources between parallel processes using the lock file mechanism [1], which consists in the fact that

- associate a shared resource with a lock file;

- create a lock file during an attempt to access a process (application) to a shared resource;

- if such a lock file already exists, this operation will be completed with an error;

- if such a lock file does not exist, a lock file is created;

- write to the just created and open lock file the data of the process that created it (for example, the process identifier, process ID (PID)), etc.);

- ensure that the process performs operations with a shared resource;

- remove the lock from the shared resource (file) by deleting the lock file.

However, this known method has a drawback. So, if the process that owns the lock ended incorrectly and did not delete the lock file, then no more processes will be able to access the shared resource, and a deadlock occurs. Accordingly, the reliability of the known method is low.

There is also a method of synchronizing access to shared resources of a computing system and detecting and removing dangling locks using lock files [2], which consists in the fact that

- associate a shared resource with a lock file;

- cause a system call of atomic exclusive creation and opening of a temporary file with a unique name and in the same file system in which it is supposed to create a lock file from the side of the current process trying to access the shared resource;

- put information on the current process, which is trying to access the shared resource, into a temporary file;

- carry out a system call to create a hard link with the name of the lock file to a temporary file;

- if the system call to create a hard link is successful, then:

- delete a hard link to a temporary file;

- ensure that the current process performs operations with a shared resource;

- delete the lock file;

- if the system call to create a hard link is made with an error, and the error is not related to the fact that the file with the name of the lock file already exists, then delete the temporary file;

- if the system call to create a hard link is made with an error, and the error is due to the fact that a file with the name of the lock file already exists, then;

- delete the temporary file;

- they search for the process specified in the existing lock file by performing the following steps:

- set the file write lock on the lock file;

- check the presence in the system of a process whose data is specified in an existing lock file;

- if the current process in the system exists, then remove the file lock on the write to the lock file;

- if the current process in the system does not exist, then the suspension is removed by performing the following actions:

- delete from the existing lock file the previous data of a nonexistent process;

- enter the data of the current process into the lock file;

- remove the file lock record from an existing lock file;

- ensure that the current process performs operations with a shared resource;

- delete the lock file.

If during the execution of the known method, after checking, it turns out that the process whose data is specified in the lock file does not currently exist in the computing system (for example, an internal software failure occurred and the application was forcibly unloaded from the main memory by the operating system (OS)) , then this will not prevent other processes from providing access to the shared resource and will ensure that there is no hanging lock.

The described method is adopted as a prototype.

However, this method also has disadvantages.

In the known method, the reliability of detecting a hanging lock depends on the information that is specified in the lock file. In general, the OS provides a unique process identifier (PID) only for currently running processes. If the process has been completed, then its PID can be assigned to another process.

In addition, the PID assigned to a specific process during OS reboot can be assigned to another process and, thus, lose its uniqueness. Accordingly, the operation of deleting the previous data of a nonexistent process (if the current process does not exist in the system) or unlocking the file lock on the lock file (if the current process exists in the system) may well be performed incorrectly, since it will relate to a process that is not associated with a shared resource .

With this in mind, for the correct PID assignment for a process that is unique among not only running processes, but also among processes that have completed work, it is advisable to develop and use a separate system in which processes will be monitored and recorded and which will monitor the activity of processes.

The absence of such a system reduces the reliability of detection and elimination of hanging locks. However, the presence of such a separate system will increase the complexity of the method and increase the consumption of computing resources (RAM and processor). This may become an obstacle to using such a solution in computing systems with limited resources (for example, embedded systems).

Disclosure of invention

The technical result is to increase the reliability of detection and elimination of hanging locks.

An additional technical result is to simplify the process of detecting dangling locks and reduce the consumption of computing resources by eliminating the process search procedure specified in the existing lock file.

For this, a method is proposed, which consists in the fact that

- associate a shared resource with a lock file;

- cause a system call of atomic exclusive creation and opening of a temporary file with a unique name and in the same file system in which it is supposed to create a lock file from the side of the current process trying to access the shared resource;

- create a recommendative exclusive lock on a temporary file;

- carry out a system call to create a hard link with the name of the lock file to a temporary file;

- if the system call for creating the hard link is successful, then the hard link to the temporary file is deleted;

- ensure that the current process performs operations with a shared resource;

- remove the hard link to the lock file;

- remove the recommended exclusive lock from the lock file;

- close the open lock file;

- if the system call to create a hard link is made with an error, and the error is not related to the fact that the file with the name of the lock file already exists, then

- delete a hard link to a temporary file;

- remove the recommended exclusive lock from a temporary file;

- close the open temporary file;

- if the system call to create a hard link is made with an error, and the error is due to the fact that the file with the name of the lock file already exists, then

- delete a hard link to a temporary file;

- remove the recommended exclusive lock from a temporary file;

- close the open temporary file; open a lock file;

- establish a recommended exclusive lock on the lock file;

- if the recommended exclusive lock on the lock file is successfully installed, then

- ensure that the current process performs operations with a shared resource;

- remove the hard link to the lock file;

- remove the recommended exclusive lock from the lock file;

- close the open lock file;

- if it was not possible to establish a recommended exclusive lock on the lock file, then the open lock file is closed.

You should pay attention to the order of actions on the lock file when releasing the resource. First, remove the hard link to the lock file, then remove the recommended exclusive lock from the lock file and finally close the open lock file. In this case, after removing the hard link to the lock file, the file on the disk continues to exist until the last one is opened in at least one process, and will be physically deleted when the last process holding the lock file open closes it. However, an attempt by another process to create another lock file or create a hard link with the name of the lock file will succeed.

It is worth noting that in the proposed method for determining whether an existing lock is dangling, there is no need to enter process information into a lock file, and there is no need to search for a process by this information. Instead, an advisory lock is installed. If for some reason the process that created the lock file in the system did not complete correctly and did not delete the lock file, then an attempt by another process to set the lock will succeed. If the process that created the lock file and holds the lock is present in the system, then an attempt by another process to set the lock will fail. All this leads to a simplification of the process of detecting dangling locks and reducing the consumption of computing resources.

It also eliminates the need for an additional system in which processes that capture the lock are recorded and which tracks their presence in the system. In this case, the reliability of detecting a hanging lock would depend on the reliability of the additional system. The absence of an additional system also simplifies the process of detecting dangling locks and reduces the consumption of computing resources.

The implementation of the invention

Implementation of the proposed method can be implemented in a computer system running a POSIX-compatible OS, in particular, GNU / Linux, where the lock file mechanism for synchronizing access to a shared resource is widespread.

A necessary condition for the implementation of the proposed method is the presence of the following tools as part of the OS of a computer system described in the standard ISO / IEC / IEEE 9945: 2009 [3]:

- system calls for working with files (open, close, link, unlink);

- support for hard links in the OS and the file system, which is supposed to create a lock file;

- operations of atomic exclusive creation and opening of a temporary file with a unique name (for example, performed using the mkstemp system call);

- support for file locks and the presence of system calls to work with them (fcntl and F_SETLKW).

All these tools are present in the GNU / Linux OS, in particular, in the Debian 6 OS distribution available for any user.

Hard links are supported by most file systems, in particular the Ext3 (Extended File System version 3) file system supported by Debian.

To implement the method in the created or modernized program or program module designed to work with shared resources, the following actions are performed sequentially.

Associate a shared resource (for example, a serial port, a database file) with a lock file. This can be done, for example, by forming a constant containing the path to the lock file.

In each process, before accessing the shared resource, they call the mkstemp system call by calling the system function of the same name, specifying the path in the same file system in which the creation of the lock file is intended as a template for creating a temporary file.

They establish a recommended exclusive write lock on a temporary file, for which they call the fcntl system call, passing the file descriptor number of the open lock file as the first parameter, F_SETLKW as the second value, and the filled flock structure as the third value to set the temporary file lock.

The link system call is called using the function of the same name, passing the path to the temporary file as the first parameter, and the path to the lock file with which the shared resource is associated as the second parameter.

If the link function returns 0, then:

- remove the hard link to the temporary file, causing the unlink system call;

- ensure that the current process performs operations with a shared resource;

- remove the hard link to the lock file, for which they call the unlink system call, passing the path to the lock file as a parameter;

- they remove the recommended exclusive lock from the lock file, for which they call the fcntl system call, passing in the number of the file descriptor of the open lock file as the first parameter, F_SETLKW as the second value, and the filled flock structure as the third value to unlock it;

- close the open lock file, calling the close system call, passing as the parameter the file descriptor number of the open lock file;

If the link function returns -1, and errno (error return value) contains an error code other than EEXISTS, then

- remove the hard link to the temporary file, for which they call the unlink system call, passing the path to the temporary file as a parameter;

- they remove the recommended exclusive lock from the temporary file, for which they call the fcntl system call, passing the file descriptor number of the open temporary file as the first parameter, F_SETLKW as the second value, and the filled flock structure as the third value to unlock it;

- close the open temporary file, calling the close system call, passing as the parameter the file descriptor number of the open temporary file;

If the link function returns -1, and errno contains an EEXISTS error code, then

- remove the hard link to the temporary file, for which they call the unlink system call, passing the path to the temporary file as a parameter;

- they remove the recommended exclusive lock from the temporary file, for which they call the fcntl system call, passing the file descriptor number of the open temporary file as the first parameter, F_SETLKW as the second value, and the filled flock structure as the third value to unlock it;

- close the open temporary file, calling the close system call, passing as the parameter the file descriptor number of the open temporary file;

- open the lock file, for which they perform the open system call, passing as the first parameter the path to the lock file with which the shared resource is associated, and as the second parameter - the reading mode, and remember the returned file descriptor number of the open lock file;

- set the file lock for the record, for which they call the fcntl system call, passing the file descriptor number of the open lock file as the first parameter, F_SETLKW as the second value, and the filled flock structure as the third value to set the file lock;

- if the operation of setting the file lock was successful, then it is believed that a hanging lock has been detected and eliminated and the current process has captured the shared resource, after which

- ensure that the current process performs operations with a shared resource;

- remove the hard link to the lock file, for which they call the unlink system call, passing the path to the lock file as a parameter;

- they remove the recommended exclusive lock from the lock file, for which they call the fcntl system call, passing in the number of the file descriptor of the open lock file as the first parameter, F_SETLKW as the second value, and the filled flock structure as the third value to unlock it;

- close the open lock file, calling the close system call, passing as the parameter the file descriptor number of the open lock file;

- if it was not possible to establish a file lock, then close the open lock file, calling the close system call, passing as the parameter the file descriptor number of the open lock file;

Implement the actions of the proposed method as part of a program or function can be a specialist in programming (programmer).

Information sources

1. Johnson M.K., Troan E.V. Application Development under Linux, 2nd ed., Moscow, 2007, pp. 231-232.

2. RF patent No. 2526282, priority dated September 21, 2012.

3. ISO / IEC / IEEE 9945: 2009 Information technology - Portable Operating System Interface (POSIX®) Base Specifications, Issue 7.

Claims (1)

A method for synchronizing access to shared resources of a computer system running a POSIX-compatible OS and detecting and removing dangling locks using lock files, which consists in
associate a shared resource with a lock file;
cause a system call of atomic exclusive creation and opening of a temporary file with a unique name and in the same file system in which it is supposed to create a lock file from the side of the current process trying to access the shared resource;
create a recommendative exclusive lock on a temporary file;
carry out a system call to create a hard link with the name of the lock file to a temporary file;
if the hard link creation system call is successful, then
delete a hard link to a temporary file;
ensure that the current process performs operations with a shared resource;
remove the hard link to the lock file;
remove the recommended exclusive lock from the lock file;
close the open lock file;
if the system call to create a hard link is completed with an error, and the error is not related to the fact that the file with the name of the lock file already exists, then
delete a hard link to a temporary file;
remove advisory exclusive lock from a temporary file;
close the open temporary file;
if the system call to create a hard link is made with an error, and the error is due to the fact that the file with the name of the lock file already exists, then
delete a hard link to a temporary file;
remove advisory exclusive lock from a temporary file;
close the open temporary file;
open a lock file;
Establish a recommended exclusive lock on the lock file;
if the recommended exclusive lock on the lock file is successfully installed, then
ensure that the current process performs operations with a shared resource;
remove the hard link to the lock file;
remove the recommended exclusive lock from the lock file;
close the open lock file;
if it was not possible to establish a recommended exclusive lock on the lock file, then open the open lock file.