Browse Prior Art Database

Queued Communication Interface

IP.com Disclosure Number: IPCOM000085877D
Original Publication Date: 1976-Jun-01
Included in the Prior Art Database: 2005-Mar-03
Document File: 5 page(s) / 41K

Publishing Venue

IBM

Related People

Collier, WW: AUTHOR [+2]

Abstract

Two different types of processors, Central Processor Unit and I/O Processor (CPU and I/OP) have to be able to communicate with each other in shared storage subject to the conditions listed below.

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

Page 1 of 5

Queued Communication Interface

Two different types of processors, Central Processor Unit and I/O Processor (CPU and I/OP) have to be able to communicate with each other in shared storage subject to the conditions listed below.

Messages must be received in the order sent. The CPU uses virtual addresses; the I/OP, real. Neither the CPU nor the I/OP must be allowed to delay the other, in order not to propagate across the interface delays which are due to error situations.

The CPU may determine that there is a need to purge a certain set of messages which were previously sent, but which may not yet have been handled by the I/OP. In particular, the communication mechanism must never appear to be full; otherwise the CPU would be waiting for the I/OP (to finish processing a message and to accept another).

Communication between the CPU's and the SSU is implemented with a set of queues. Since the atomic instructions available to the I/OP are primitive, the operations to be performed on each queue by a process must be limited in complexity of interaction with other processes. Therefore, each I/OP has a separate set of queues and each queue is one-way. Since, further, the CPU has to be able to send a high-priority (purge) message to the I/OP, there are two CPU to I/OP queues (one normal priority and one high priority) and one I/OP to CPU queues per I/OP, for a total of six queues per system.

Although each I/OP accesses only a predefined set of queues, each CPU can access any of the six queues.

When a CPU places a message on any of the queues, it signals the I/OP associated with the queue. When an I/OP places a message on a queue, it issues a signal which is taken by any available CPU.

To simplify the interaction among CPU's there is a lock which allows only one CPU at a time to access the queues. Since each I/OP accesses a separate set of queues, there is no contention between I/OP's and thus no need of a lock to reduce contention. It is not possible to serialize operations between the one CPU and the one I/OP operating on a queue at the same time, so it is required that the two processors cooperate constructively in accessing the queues. Queue elements have the following format:

(Image Omitted)

The virtual and real addresses both point to an I/O element which describes the I/O operation to be performed. Queue elements are not linked together in the conventional fashion. Instead, to save space, they are grouped together into (say, 1K) contiguous blocks of storage called sections. Each section contains 2**n queue elements, of which 2**n-1 elements point to I/O control blocks and one element, the last element, which points to the next section. One of the flags in the element state field, called the chain-bit, distinguishes the two uses of the element.

1

Page 2 of 5

The sections of a queue are chained together in a ring (there is no tail section). The effect is to cause the elements to appear to be chained together in a ring.

For each queue the...