Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Serialization Reduction in X-Memory Communications

IP.com Disclosure Number: IPCOM000106111D
Original Publication Date: 1993-Sep-01
Included in the Prior Art Database: 2005-Mar-20
Document File: 2 page(s) / 92K

Publishing Venue

IBM

Related People

Avis, MJ: AUTHOR

Abstract

Disclosed is a technique which avoids excessive queueing for a cross-memory lock when requesting asynchronous services from another address space. Long cycle times in Multiple Virtual Storage (MVS) cross memory accesses are reduced.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Serialization Reduction in X-Memory Communications

      Disclosed is a technique which avoids excessive queueing for a
cross-memory lock when requesting asynchronous services from another
address space.  Long cycle times in Multiple Virtual Storage (MVS)
cross memory accesses are reduced.

     In Multiple Virtual Storage, when an address-space requests an
action from a sub-system via the PC instruction, the action may be
executed synchronously by code in the called address-space being
dispatched as part of the calling address-space, or asynchronously,
when the code in the called address-space merely queues the request
for subsequent action by tasks dispatched as part of the sub-system.
In the asynchronous case, if storage is acquired by the GETMAIN
facility, then the cross-memory lock must be obtained, effectively
serialising the processing.  The process disclosed to reduce this
serialisation could have applicability in other sub-systems which
utilise the asynchronous approach.

     The sub-system maintains, in its own address-space, a
last-in-first-out (LIFO) ordered queue of areas of storage which are
used to save the description of the requested action; these areas are
subsequently referred to as "work elements".  When a cross-memory
call is received, one of these areas of storage is dechained using a
compare & swap instruction to maintain the integrity of the queue.
If no such area is available, a page of storage is acquired, via the
GETMAIN facility, and it is formatted into a number of areas of
storage, each of which is added to the LIFO queue.  It is only during
this part of the process that any serialisation is forced by the use
of the cross-memory lock.  In a system for which the number of
requests that may be outstanding at any instant is a finite function
of the number of address-spaces and other factors such as number of
peripherals, then the number of GETMAINs issued will be limited
during the life of the sub-system address-space.

     Once the request is complete, the area of storage that described
the request is returned to the queue from which it was initially
acquired.  Once the details of the requested action are placed in the
acquired storage, the cross-memory code searches for an available
task to execute...