At 17:29 -0400 on 06/16/2014, John Gilmore wrote about Re: RENT, REFR
and key=0 storage - A correction:
Consider an inventory record, for concreteness one that contains a
count of the number of pairs of size 13EEE black oxfords in some
wholesaler's stock, and two programs, A and B.
B queries this record, finds that it contains a count of 20 pairs, and
withdraws 5 pairs from and updates the record to reflect the new count
of 15. After B's query but before but before B's update A also
queries this record and withdraws 10 pairs. B updates the record to
reflect a new count of 20 pairs. A then updates it to reflect a new
count of 10 pairs. In the upshot the inventory record reflects a
balance of 10 pairs when it should reeflect a balance of only 5 pairs.
Scenarios of this kind that differ only in detail can be multiplied ad
infinitum et nauseam. Does either of you judge
o that serialization cannot prevent them, or
There are multiple ways to avoid the run condition that stores a bad
result. One is to serialize on the field so you insure that the field
can not be accessed by A until B has stored its updated result back.
Another is to verify that the expected value is still there when you
try to overlay it with a new value (IE: Use a CS to check the current
value and store the new one). If the expected value is altered behind
your back you retry the CS with a new expected and replacement value.
The CS retry logic will also catch the case where there is not enough
stock to service both updates. It drives the same error logic as
would occur if you tried removing more stock than there was. In the
case where B wanted 10 pair and ran reducing the stock to 10 and THEN
A ran wanting 15 pair, A would fail. Running both at the same time
using CS, the compare part of the CS would fail for one of them and
in the retry logic where you would make a new expected and
replacement value before reissuing the CS, you make sure that the new
expected value is more than the amount you are reducing it by.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
