Browse Prior Art Database

Implementing A Thread Buffering Service As An Installable Product Or A Built-In Function Of An Operating System

IP.com Disclosure Number: IPCOM000241166D
Publication Date: 2015-Mar-31
Document File: 3 page(s) / 66K

Publishing Venue

The IP.com Prior Art Database

Abstract

A method and system is disclosed for implementing a thread buffering service as an installable product or a built-in function of an operating system.

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

Page 01 of 3

Implementing A Thread Buffering Service As An Installable Product Or A Built -
-In

In

Function Of An Operating System

Serializing and merging multiple producer threads into a single consumer thread is part of a broad variety of products. For example, a data collector of a monitor captures and consumes real-time events. The captured data is serialized before consumption. In cases when data consumption means simply logging some captured data records, the system logger directly plays the role of a consumer invoked by each producer thread. In other cases, consumption of the captured data may involve a lot more than just logging, or even no logging at all. Here, the consumer needs to aggregate or summarize records before deciding whether and/or what and/or where to externalize or discard the records. Known implementations by software products are tightly embedded in the product and are not readily exploitable externally. A typical result of merging threads is a consumer bottleneck that occurs during peak workloads when the consumer, even performing at top speed, is still slower when compared to the combined output speed of serialized producers. Some applications forbid injecting a WAIT into a producer thread or otherwise artificially slowing it down, so the only way to relieve the bottleneck is a buffering mechanism that absorbs the overflow until the peak eventually subsides. A readily available standard service is considered to serialize, buffer, and provide bottleneck relief to enable application developers to use an

Application Programming Interface (API) to invoke a standard service rather than building one. The standard service is a tremendous savings on development that is comparable to using the high-level API provided by file access methods as opposed to

writing a buffering logic, physical I/O routines, and channel programs.

Disclosed is a method and system for implementing a thread buffering service as an installable product or a built-in function of an operating system. An instance of the thread buffering service includes consumer task, producer tasks (multiple or single), buffer, and Service Control Block (SCB). There may be any number of instances in the thread buffering service that may be cascaded to enable consumers of one instance to feed data to a producer of another for aggregation of data from disparate data collectors.

In accordance with the method and system, a thread buffering service framework includes the architecture and the API. The thread buffering service supports the API calls that are issued from either a single or multiple address spaces.

In an embodiment, an application creates a consumer task via a CREATE call. A user exit routine is supplied on the CREATE that contains application logic for record processing. A name that producers use to connect to the thread buffering service, as

well as parameters for SCB such as buffer size, frequency of POST by Producers, Consumer's time interval is also supplied...