Browse Prior Art Database

Method to Suspend and Resume the Processing of Serialized Synchronous Requests

IP.com Disclosure Number: IPCOM000109263D
Original Publication Date: 1992-Aug-01
Included in the Prior Art Database: 2005-Mar-23
Document File: 6 page(s) / 260K

Publishing Venue

IBM

Related People

Harter, JL: AUTHOR [+5]

Abstract

A method is described to requeue requests that are waiting for some other request to complete, as well as how to retry the requeued requests at a later time, namely after the needed request (callback response) has been processed. This method avoids a deadlock situation in an opportunistic locking environment.

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

Method to Suspend and Resume the Processing of Serialized Synchronous Requests

       A method is described to requeue requests that are
waiting for some other request to complete, as well as how to retry
the requeued requests at a later time, namely after the needed
request (callback response) has been processed.  This method avoids a
deadlock situation in an opportunistic locking environment.

      The method described in this article provides a solution to an
opportunistic locking deadlock condition. When the second request
from the workstation attempts to lock the file that was previously
locked opportunistically by the same workstation, the host file
server is immediately notified that a callback has been sent to the
same workstation that is requesting this lock.  The host file server
uses this method to save status information and 'requeue' this
request for processing at a later time.  Since the host file server
is no longer processing this request for the user, it is free to
process other requests that come in from the same user.  One of these
'other' requests will be the callback response from the user that
releases the opportunistic lock that was held.  This method describes
how the host file server 'requeues' requests that are waiting for
some other request to complete, as well as how the host file server
retries the 'requeued' requests at a later time, namely after the
needed request (callback response) has been processed.

      Essential Elements of the Method
           o  Queued User Request Block
           o  A requeued user request chain for requeued work
requests
           o  State Info Block for restarting a request
           o  Method to requeue work requests that cannot be
processed to completion
           o  Algorithm to determine when to process requeued
requests and how often
/**************************************************************/
/*
*/
/*   User request handling and requeueing data structures
*/
/*
*/
/**************************************************************/
typedef                       /* essential contents of userblock */ {
  QUR   *new_request_chain_anchor           /* ptr to QUR chain  */
  QUR   *requeued_request_chain_anchor      /* ptr to QUR chain  */
  int    number_of_requeued_requests        /* counter */
  flag   need_new_request                   /* binary flag */
} userblock
typedef /* essential contents of Queued User Request (QUR) block */ {
  void  *request_block_address              /* ptr to request    */
  void  *state_info_address                 /* ptr to state info */
} QUR
/**************************************************************/
/* ROUTINE: Requestor Dispatcher */
/* */
/* PURPOSE: */
/* */
/*   This routine gets control form the system after the system  */
/*   receives a u...