Browse Prior Art Database

Token for controlling access to mechanism by different processing paths

IP.com Disclosure Number: IPCOM000129215D
Original Publication Date: 2005-Oct-01
Included in the Prior Art Database: 2005-Oct-01
Document File: 2 page(s) / 59K

Publishing Venue

IBM

Abstract

Disclosed is a method by which the control, use, and assignment of resources is synchronized by using a logical entity called a token. In the process of printing jobs, print data is rasterized and then forwarded to the mechanism component for printing on a physical printer. The printer supports multiple data streams (e.g. IPDS, Postscript, PCL, etc.). Multiple data paths exist in the printer, each with different rules of operation between the rasterizor, mechanism and other components. Some rules involve mutually exclusive use of certain resources, such as the input queue to the mechanism. The disclosed method provides the required synchronization and control for processing jobs through multiple data paths.

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 52% of the total text.

Page 1 of 2

Token for controlling access to mechanism by different processing paths

A logical entity called a "token" is defined to synchronize and control the use of certain mutually exclusive resources. The token is similar to, but not the same as, a semaphore. A semaphore blocks program execution; the token (or lack of it) blocks the processing of data, but does not block program execution. In one implementation the token is referred to as the MechToken. The holder of the MechToken is allowed to make calls to the side builder and issue ss_putQueue's to the input data queue of the Mechanism component. No such calls or put's can be issued without first obtaining the token.

The ASCII and IPDS data paths (see Figure 1) both require certain mutually exclusive resources. The token is used to clear the data paths used by ASCII or IPDS in preparation for switching from one type of job to another. The token represents the logical "end" of a stream of jobs through a printer's job data path. The token changes hands only when switching from ASCII to IPDS or IPDS to ASCII, or other similar mutually exclusive data paths. It is not released "automatically" by the holder at the end of a job. Its release is triggered by the Mux component.

The token is acquired from the Mechanism component by sending and receiving a message. The token is lost (released) when a MechToken data block passes through the owning component's data queue. The token is initially owned by the Mechanism component. The token is requested and released using messages to the Mechanism component. Components that request the token are all of the components that issue putQueue's to the Mechanism input queue. Namely, IPDS, Pipeline A (normal), and Pipeline B (ripQ).

In order for a component to use the side builder, or put pages on the Mechanism data queue, it must hold the MechToken. If the component doesn't already hold the token, it must acquire it. To do so, the component sends a RequestMechToken message to the Mechanism and waits for a DeliverMechToken message. At some future time the Mechanism will send a DeliverMechToken message. The time delay between token requested and token received will generally be short. This is because the only reason that a component would be in a position to request the token is that a job has...