This question's explanation and your answers so far.
ある在庫管理システムは，複数の入力を同時並行して処理し，在庫数を更新しているが，排他制御は行っていない。ある時点での在庫数が 100 であったとき，入力された二つの入力 A，B に応じて，図に示す処理が ① → ② → ③ → ④ の順序で実行された場合，処理④が終了した時点の在庫数は幾つになるか。 在庫管理システム
| 入力 | 処理内容 |
|---|---|
| 入力A | ① “在庫数”を読み込み，入庫数の 50 を加える。<br>④ 結果を“在庫数”に書き込む。 |
| 入力B | ② “在庫数”を読み込み，出庫数の 30 を引く。<br>③ 結果を“在庫数”に書き込む。 |
70 is the stock quantity at the end of step ③, that is, immediately after Input B writes the result of “100 − 30”. What the question asks for is the value at the moment processing ④ finishes, and in the following step ④ Input A overwrites it with the 150 it had calculated back at step ①, so 70 does not remain as the final value. Conversely, if steps ③ and ④ were swapped (A writes first and B writes later), the answer would be 70.
100 is simply the initial stock quantity as it was before any update. Even without exclusive control, a lost update wipes out only one side's update; the result of step ④, which performs the last write (= 150), is certainly reflected in the data. This is not a situation in which the updates of both Input A and Input B are voided together, so the value cannot stay unchanged at 100.
120 is 100 + 50 − 30, the value when both Input A's and Input B's updates are correctly reflected — in other words, the stock quantity that should properly be obtained if exclusive control were performed correctly and A and B were serialized (one of them finishes everything from reading to writing before the other starts). This question is exactly the case where that exclusive control is not performed: both ① and ② read the value 100 from before any write, so the result does not become 120. The gap between this choice and the correct answer (30, the difference between 150 and 120) corresponds to the lost outgoing amount of Input B.
正解 The correct answer is エ, 150. Because no exclusive control (locking) is performed, when Input A and Input B read and write the same shared data, the “stock quantity”, their updates are not protected from each other, and what is called a lost update (an update that disappears because it is overwritten) occurs. Following the processing one step at a time in the order ① → ② → ③ → ④ gives the following. First, the stock quantity in the initial state is 100. In ①, Input A reads the “stock quantity”, adds the incoming amount of 50 to the 100 it read, and holds 150 in its own working area — at this point nothing has been written yet, so the stock quantity in the database is still 100. Next, in ②, Input B reads the “stock quantity”, but since A's result has not been reflected yet, the value B can read is also 100; subtracting the outgoing amount of 30 from it, B holds 70 in its own working area. In ③, Input B writes 70, so the stock quantity becomes 70. Finally, in ④, Input A writes, just as it is, the 150 that it calculated and held back at step ①. This write overwrites the 70 that B wrote, so the stock quantity at the moment processing ④ finishes is 150. In other words, the reflection of Input B's outgoing amount of 30 is completely lost, and this is the typical error of concurrent updating without exclusive control.