Telecommunications – Radiotelephone system – Zoned or cellular telephone system
Reexamination Certificate
2000-05-05
2003-07-22
Le, Thanh Cong (Department: 2684)
Telecommunications
Radiotelephone system
Zoned or cellular telephone system
C455S424000, C455S450000, C455S509000
Reexamination Certificate
active
06597907
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field of the Invention
The present invention relates in general to the field of network systems, and in particular, by way of example, and not limitation, to detection of a deadlocked resource condition in a pool of shared resources.
2. Description of Related Art
In a typical network system, such as a telecommunication system or data network system, the network maintains centralized control over available resources, and allocates these resources to individual devices or processes in response to a resource request. This centralized control enables the network to share the available resources among a larger number of users, thereby allowing network operators to offer a greater level of service at a lower cost. The sharing of resources among potentially competing devices or processes, however, causes network systems to be susceptible to resource conflict. This problem arises when two or more devices or processes attempt to access the same resource during the same time interval. These potentially conflicting uses of shared resources require the network system to maintain an established protocol that enables either the network or individual devices or processes to determine when access to a given resource is permissible.
Resource locking is one technique commonly employed in network systems to avoid resource conflicts. This technique utilizes a protocol in which the network signals the use of a resource by marking the resource as “used” or “busy.” This notifies the network and/or competing processes that the resource cannot be accessed at that time. In operation, a process desiring access to a particular resource inspects the lock or flag associated with that particular resource before submitting a resource request. Alternatively, the network inspects the flag associated with the resource before allocating the resource to the particular process. If the flag indicates that the resource is currently “free” or “idle,” the process is allocated the resource, uses the resource, and then releases the resource when the process is finished. On the other hand, if the flag indicates that the resource is “used” or “busy,” the process and/or network waits for the resource to be released by the prior acquiring process before allowing access to the resource.
If the network system configures the available resources into one or more pools of similar or identical resources, the resource locking technique may employ a “seizure” mechanism that attempts to seize a free (available) instance of a resource from the resource pool and allocate the seized resource to the requesting device or process. This seizure mechanism typically utilizes a search strategy or a linked list approach to identify free instances of the requested type of resource. If a search strategy is used, for example, the pool of the appropriate type of resource is examined in a specified order until a free resource is found and seized or the search is abandoned because it is determined that there are no free resources within the resource pool. If the linked-list approach is used, on the other hand, the first item of the linked-list (if there is an item in the linked-list) represents an available instance of the resource. This resource may then be seized by the seizure mechanism by changing the state of the found resource from idle to busy. Regardless of the type of seizure approach used, the end result will be either identification of an available resource within the resource pool or a report back to the device or process originally requesting the resource that “congestion” has occurred and, thus, no free resources of the type requested are currently available. If an instance of the resource is found and seized by the seizure mechanism, the seized resource is effectively locked or otherwise prevented from being seized again until the seized resource is freed by the reverse of the seizure mechanism.
One undesirable situation that can arise in a resource locking scheme is a “deadlocked resource condition.” For the purposes of the present invention, a deadlocked resource condition occurs when a device or process that has been allocated a shared resource fails to release the resource for illegitimate reasons, such as an error in communications, an error in system or application software, or an undesired operational state. For example, an error in the system or application software may cause the process or network to fail to release the resource when the process is complete, or the signal releasing the shared resource may not be received due to an error in communications. Moreover, the process to which the resource is allocated may encounter an unexpected error and self-terminate, or the process may be terminated (“killed”) by the operating system or another process without releasing the resource. This situation is referred to as process death, and may cause the shared resource to remain locked by the dead process potentially forever.
A deadlocked resource condition may also occur due to conventional deadlock between competing processes. This conventional deadlock situation arises when a first process attempts to acquire a resource that is already locked by a second process, and the second process likewise attempts to acquire a resource that is already locked by the first process. Since neither process is able to release the lock sought by the other, neither process cane proceed. Both resources will remain locked until one of the conventionally deadlocked processes is terminated to allow the other process to continue.
If a deadlocked resource condition is not detected and corrected, and if the process or processes continue to cause deadlocked resource conditions due to a reoccurring error or reoccurring operational state, all available resources will be gradually consumed. This situation leads to a gradual degradation in the quality of service offered by the network, until the network eventually ceases to function. Therefore, in a network system which employs a resource locking scheme, there must be a mechanism for detecting a deadlocked resource condition in time for network operators or system software to take corrective action, such as temporarily assigning additional resources to allow the network some ability to function, restarting the network to clear deadlocked resource conditions, and actually fixing the problem causing the deadlocked resource condition.
Existing approaches have attempted to alleviate the problems described above by utilizing either a timer-based or logic-based solution or by monitoring traffic congestion. In a timer-based solution, a separate timer is initiated for each resource allocation. If the resource remains locked after a predetermined amount of time has expired, the network assumes that a deadlocked resource condition has occurred, terminates the process, and releases the resource. Although a timer-based solution has the potential to correctly detect deadlocked resource conditions in situations involving a definite upper time limit of resource usage, this solution proves to be inadequate in situations where the upper time limit is relatively long or indefinite. For example, because users will only (normally) tolerate a call setup that is measured in seconds and is well under a minute in maximum duration, the timer-based solution may perform well in situations where the resources are allocated for call setup only and are not used once the call has been completely established. The call itself, however, can last indefinitely, and multi-day long calls are not impossible. Thus, in order to avoid disconnecting a valid, but relatively long, call, a deadlock detection timer must be configured with a time interval that is so long as to be impractical for early detection of deadlock resource conditions. If deadlocked resource conditions were to start occurring frequently, the whole pool of resources may be consumed before the first timer expires. Furthermore, at least one timer must be separately maintained for each seized resource, thus adding to the cost of implementation, m
Campbell Loudon Lee
Kocaturk Mustafa
Pruitt Leonard
Cong Le Thanh
Ericsson Inc.
Jenkens & Gilchrist P.C.
Trinh Tan
LandOfFree
Detection of a deadlocked resource condition in a pool of... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Detection of a deadlocked resource condition in a pool of..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Detection of a deadlocked resource condition in a pool of... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3030123