Browse Prior Art Database

Stopping Queue Servicing when No Servicing is Possible

IP.com Disclosure Number: IPCOM000237046D
Publication Date: 2014-May-28
Document File: 6 page(s) / 200K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed are a system and method to stop queue servicing when no servicing is possible. The method wakes up the servicing process when another code determines that conditions have changed, such that data might now be successfully processed.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 32% of the total text.

Page 01 of 6

Stopping Queue Servicing when No Servicing is Possible

In environments where data cannot be immediately processed, it is added to a queue and processed later. Typically, a servicing process is run to service one or more queues and process the data. The servicing process may run endlessly looking for data to process, or it may go to sleep when all queues become empty, to be awakened when a queue is no longer empty. Additional

complex conditions can result in the servicing process endlessly running, even though the queues are not empty; however, no

data is successfully being processed.

Allowing the servicing process to endlessly run when no data is being processed is a waste of limited Central Processing Unit

(CPU) and memory resources. These resources could be better utilized running some other productive process.

A method is needed by which the servicing process can determine whether any data is being successfully processed; if no data is being processed, and then automatically place the servicing process into sleep mode.

The novel contribution is an apparatus and method to stop queue servicing when no servicing is possible. The method wakes up the servicing process when another code determines that conditions have changed, such that data might now be successfully processed.

The design includes a Fibre Channel (FC) Adapter Port Object instance for each FC port on the Primary controller. Each FC

Adapter Port Object instance contains four anchors for four different queues, one for each priority. These queues are part of the upper tier of queues.

Figure 1: Basic design

1


Page 02 of 6

Each Extent Pool has an Extent Pool Object instance. Each Extent Pool Object instance contains four anchors for four different queues, one for each priority. These queues are part of the upper tier of queues.

Figure 2: Position of Extent Pool

Each time that work is done to synchronize a volume on the Primary controller with a volume on a Secondary controller, the system adds a Volume Relationship Object instance to multiple queues. The Volume Relationship Object is added to the end of a priority queue for each of the FC Adapter Port Object instances and to the end of a priority queue for the Extent Pool Object instance, simultaneously.

If all of the queues for an FC Adapter Port Object instance are empty and then a Volume Relationship Object instance is added to one of the queues, the FC Adapter Port Object instance is added to the FC Adapter Port List, which is a list containing only those

FC Adapter Port Object instances which have non-empty queues.

Similarly, if all of the queues for an Extent Pool Object instance are empty and then a Volume Relationship Object instance is added to one of the queues, the Extent Pool Object instance is added to the Extent Pool List, which is a list containing only those

Extent Pool Object instances which have non-empty queues.

2


Page 03 of 6

Figure 3: FC Adapter Port Lists

A Volume Relationship Finder process searches...