Resource locking approach

Details Resource locking approach Resource locking approach

1999-05-07

2003-03-25

Thai, Xuan M. (Department: 2181)

Electrical computers and digital data processing systems: input/

Access locking

C714S006130

Reexamination Certificate

active

06539446

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to information systems, and more specifically, to an approach for providing access to resources in information systems.
BACKGROUND OF THE INVENTION
In information systems, processes require access to resources to perform work. As used herein, the term “resource” refers to any object that can be accessed in an information system. In a hardware context, examples of resources include, but are not limited to, printers, disk drives and memory. In a software context, examples of resources include, but are not limited to, data items and routines. In information systems it is often desirable to allow only one process at a time to access a particular resource to maintain consistency. For example, if while a first process is updating a particular resource, a second process is allowed to read from the particular resource, then the second process may read an intermediate value of the particular resource that is different than the final value of the particular resource after the first process has completed its updates. As a result, the second process may erroneously believe that at the time the second process read from the particular resource, that the particular resource reflected all of the changes made by the first process. In this situation, an inconsistency has been introduced into the information system with respect to the value of the concurrently accessed particular resource, thereby compromising the integrity of the data on the information system.
To address situations such as this, various mechanisms are used to ensure the integrity of resources that can be accessed by multiple processes. One type of mechanism used to coordinate access to shared resources is referred to as a lock. In its most general form, a lock is data that indicates that a particular process has been granted certain rights with respect to a resource. There are many types of locks. The type and parameters of a lock determine the scope of the access rights granted to the process that holds the lock. For example, shared locks may be shared on the same resource by many processes, while exclusive locks are only granted to a single process and prevent other locks from being granted on the same resource.
In the previous example, the first process would request and be granted a lock on the particular resource prior to updating the particular resource. While the first process holds the lock on the particular resource, the first process may make updates to the particular resource, but the second process may not access the particular resource. Once the first process has completed updating the particular resource, the lock is released. The second process can then access the particular resource and see all of the updates made to the particular resource by the first process.
Locks are typically allocated and managed by an entity referred to as a lock manager. Lock managers are responsible for maintaining data that specifies the status of locks for a set of resources. Lock managers sometimes also maintain a lock request queue that specifies pending lock requests for resources managed by the lock managers. In distributed computing systems, lock managers and their assigned resources may reside on different nodes, or may be located on the same node. As used herein, the term “node” refers to any type of computing entity. Thus, a single computer may either be a single node or support multiple nodes.
One of the problems with locking mechanisms is that when a particular lock manager fails, or the node on which the particular lock manager resides fails, the lock data maintained by the particular lock manager can be corrupted or lost. Specifically, the data that specifies the status of locks for the particular resources assigned to the particular lock manager and the lock request queue data can be corrupted or lost.
One of the consequences of this type of failure is that it is not immediately known which resources associated with the lost lock data were locked by processes at the time of the failure. As a result, no new locks can be granted on the resources until the lock data is re-built which can cause undesirable processing delays. These resources are sometimes referred to as “frozen” resources.
FIG. 1
is a block diagram of a distributed computing arrangement
100
on which a conventional locking mechanism is employed. Arrangement
100
includes three nodes, identified as NODE
1
, NODE
2
, NODE
3
and a resource R
1
. A lock manager LM resides on NODE
2
and is responsible for managing access to resource R
1
. Specifically, lock manager LM grants locks to processes that require access to resource R
1
. Lock manager LM may also be responsible for managing access to other resources (not illustrated).
Lock manager LM generates and maintains lock data
102
on NODE
2
. Lock data
102
contains data that specifies what processes, if any, have been granted locks on resource R
1
. Lock data
102
also contains data that specifies any pending lock requests for resource R
1
. When a change in lock status for resource R
1
occurs, for example when a new lock is granted or when an existing lock is released, lock manager LM causes lock data
102
to be updated to reflect the change in lock status.
Suppose process P
1
requires access to resource R
1
. Process P
1
requests a lock on resource R
1
from lock manager LM. Lock manager LM determines whether any other processes currently hold locks on resource R
1
that are incompatible with the lock requested by process P
1
. If no other processes currently hold locks on resource R
1
that are incompatible with the lock request from process P
1
and if there are no other pending lock requests for resource R
1
, then lock manager LM grants a lock on resource R
1
to process P
1
by updating lock data
102
and notifies process P
1
that a lock on resource R
1
has been granted to process P
1
. Once process P
1
receives the lock grant notification, process P
1
can access and update resource R
1
. When process P
1
no longer requires access to resource R
1
, process P
1
notifies lock manager LM accordingly. Lock manager LM then releases the lock on resource R
1
to process P
1
by updating lock data
102
.
Suppose that while the lock on resource R
1
is granted to process P
1
that lock data
102
is lost or otherwise becomes unusable, for example by a failure of lock manager LM or a failure of NODE
2
. In this situation, the resource management duties previously performed by lock manager LM are assigned to another lock manager (not illustrated) and lock data
102
must be re-generated. Determining which processes had locks on resource R
1
is usually obtained from the processes themselves. For example, this may be accomplished by broadcasting a message to all processes that a failure has occurred and requesting processes that held locks on resources managed by lock manager LM to inform the new lock manager about the locks they held. In addition, the new lock manager will need to know which processes had pending requests for a lock on resource R
1
in a lock request queue of lock data
102
. If the lock requests cannot be determined from the processes, then processes will have to re-submit lock requests on resource R
1
to the new lock manager. During the time that lock data
102
is being re-generated, resource R
1
is frozen, meaning that no new locks are granted on resource R
1
.
In situations where lock manager LM was responsible for managing access to a large number of resources, re-generating lock data
102
can require a large amount of time and system resources. Moreover, all resources managed by lock manager LM must be frozen during recovery since it is not known whether any processes held locks on those resources. This can have a significant adverse affect on other processes that require access to any resources that were managed by lock manager LM. Furthermore, in situations where a determination cannot be made as to which processes held locks on resource R
1
at the time of the failure, the processes that held locks on resource R
1

Affiliated with

Also associated with

Rating

Resource locking approach does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Resource locking approach, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Resource locking approach will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3056955