Browse Prior Art Database

Elimination of Locks in Systems Performing Multiple Processes

IP.com Disclosure Number: IPCOM000116100D
Original Publication Date: 1995-Aug-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 4 page(s) / 95K

Publishing Venue

IBM

Related People

Appleby, R: AUTHOR [+4]

Abstract

In a system performing a number of processes, the situation can arise where multiple threads of work are adding data to a disk dataset. When this dataset becomes full, it becomes necessary to extend the dataset.

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

Elimination of Locks in Systems Performing Multiple Processes

      In a system performing a number of processes, the situation can
arise where multiple threads of work are adding data to a disk
dataset.  When this dataset becomes full, it becomes necessary to
extend the dataset.

The usual solution is for each thread of work to:
  1.  At the start of the process, check that an extend was not in
       progress.  If not, begin the add data process.
  2.  If an extend is in operation, suspend the thread by getting a
       latch or lock.
  3.  Check at various times to see that an add data operation has
not
       begun while the extend is in progress.  If it has, retry at
       step 1.

      This impacts each and every thread, whether or not the data set
is full, and adds unnecessary instructions for every thread, not just
those that wish to extend the dataset.

      The solution proposed here requires each thread that wishes to
extend the data set to place work on a queue destined for another
unit of work.  This queue of work will be processed consecutively -
not in parallel - and not in any pre-determined order.

      The data associated with a queue element contains a data item
that represents the maximum size of the dataset at the time the work
was placed on the queue.

      EXAMPLE 1, 5 threads A, B, C, D and E are processing a data
set.  They all see that the maximum size of the dataset is 26
(records/tracks/cylinders), so they each put 26 in their queue
element.

      The first queue element will be processed in isolation.  As
part of its processing, it independently determines the maximum size
of the dataset.  If this is 26, and it matches that in the queue
element that it is currently processing, then it has determined that
the dataset does need extending.

      The extend is performed, control is returned to the caller,
which retries the operation.

      The next queue element is processed.  Now the maximum size of
the data set is discovered to be 52 say, and since this does not
match the 26 in the queue element the work is deemed to have been
done, and control is returned to the caller, with a return code that
instructs him to retry the operation - which may now succeed, or a
new queue element is formed with a value of 52.

      Thus, each thread is delayed by the single threaded queue
mechanism, but only when an extend is required.

      The normal case of adding data to a dataset that is not full is
not increased by one extra source instruction.

      In a running system, the first requester of an extend may not
be the first caller to retry the operation, so the whole process will
be repeated until each thread is successful, or the data set has used
all allocated space, and then all future add requests will be failed.
                    Parallel...