Browse Prior Art Database

Serialization of Dependent Processes

IP.com Disclosure Number: IPCOM000080223D
Original Publication Date: 1973-Nov-01
Included in the Prior Art Database: 2005-Feb-27
Document File: 2 page(s) / 29K

Publishing Venue

IBM

Related People

McKinstry, RH: AUTHOR

Abstract

Process 1 collects information from a table or set of tables and must insure that process 2, which changes or updates the table, does not run during the collection. If process 1 requires the services of process 2, normal serialization techniques such as ENQ/DEQ or SETLOCK would not work because they prevent one process from running while the other is active. Described below is a technique by which process 1 can recognize that process 2 has run, without preventing process 2 from running.

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

Page 1 of 2

Serialization of Dependent Processes

Process 1 collects information from a table or set of tables and must insure that process 2, which changes or updates the table, does not run during the collection. If process 1 requires the services of process 2, normal serialization techniques such as ENQ/DEQ or SETLOCK would not work because they prevent one process from running while the other is active. Described below is a technique by which process 1 can recognize that process 2 has run, without preventing process 2 from running.

The technique uses a system serialization function such as ENQ or SETLOCK and a counter associated with the table. When process 1 runs, it first enqueues on the counter, obtains (1) the value of the counter and then dequeues. It then uses (2) or collects information from the table. Afterwards, it again enqueues, obtains (3) the value of the counter, dequeues and compares the counter value against that obtained in step (1). If the two values are the same, process 1 has had a valid run. If the values are different, process 1 should be repeated until the values are the same. This allows process 1 to use
(6) the services of process 2. When process 2 runs and has to update the contents of the table, it first enqueues, then increments (4) the contents of the counter to thereby reflect a change. Then, in step (5), the contents are updated. Afterwards, it dequeues. This technique is applicable for both multiprocessing and multiprogramming environments,...