Browse Prior Art Database

Sequential Processing of Resources in a Multithreaded Environment Disclosure Number: IPCOM000012725D
Original Publication Date: 2003-May-22
Included in the Prior Art Database: 2003-May-22
Document File: 3 page(s) / 61K

Publishing Venue



This article defines a software mechanism that solves the problem of processing resources sequentially in a multithreaded environment. Without this mechanism, software applications risk processing resources in a nondeterministic order and potentially generating inaccurate results.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 48% of the total text.

Page 1 of 3

Sequential Processing of Resources in a Multithreaded Environment

Sequential processing of resources (e.g., messages) of various affinities is a common requisite in some software applications. The chronological processing of these resources must occur in order to maintain data integrity and consistency. This need results from dependencies on the output of a previous resource affecting a subsequent related resource. An example is where an ADD CUSTOMER request is followed by an UPDATE request, where UPDATE is dependent on the existence of the customer ADD being properly processed.

An assumption is that a logical communications channel exists as the delivery mechanism to receive the incoming resources. It may be a message-oriented middleware queue, a software socket, a file, or some other means that is capable of transporting data. For instance, if a particular application uses WebSphere MQ* for the transmission of messages, then the communication channel is a WebSphere MQ queue. Another assumption is the communication channel initially receives resources in an ordered sequence or provides an indication of chronological sequence.

In a multithreaded environment where one of N executing threads processes a resource, there is no guarantee as to what the order of processing will be. While the processing order of each resource can be assigned upon the receipt of the resource, the actual thread of execution may not retain that order due to the operating system's thread scheduling management. In addition, even if the scheduler initiates threads in the designated order, there is no assurance that this order is maintained by each thread through its completion.

The software mechanism applies a thread management control procedure to resources as soon as they are received. This procedure ensures that resources are processed in the correct order. Resource affinity determines the processing order, where affinity is any element of a resource that uniquely identifies it. For instance, the affinity element for resources in a software application dealing with inventory items could be the SKU value which identifies the item uniquely. This mechanism checks the affinity element of each incoming resource to determine if processing of a similar resource (i.e., resource with same affinity element) is currently in process or waiting to be processed. An execution thread starts processing a resource if and only if there is currently no resource with the same affinity being processed. Otherwise, processing of the most recent resource is not started until processing of the previous affinity related resource completes. An in-memory hashtable structure stores the affinity element value along with the associated thread of execution in order to allow multiple resources with the same affinity element to be processed sequentially. This software mechanism includes the following design pattern characteristics:

1. Receive the original resource by the Resource Receiver Th...