tc_data$loop_lock_time overflows

[anonymous]

The “lockless” mufti-threaded emulator experiences a overflow fault when updating tc_data$loop_lock_time in pxss.alm after a week heavy load in a 4 CPU configuration.

loop_lock_time is (incorrectly) declared in tcm.incl.pl1 as

2 loop_lock_time fixed bin (18), /* time looping on the APT lock */

and treated as a signed 36 bit integer by pxss.alm.

Many of the accumulated time meters in hardcore were been switched to 'fixed bin (71)' during Multics development [Olin Sibert, personal communication]; the same treatment should be applied to loop_lock_time, a small increase in overhead as defensive programming.

It is thought that the 'lockless' emulator may accumulate lock wait times disproportionately due to poor thread scheduling as compared to the fixed scheduling structure of the canonical hardware.

[Eric Swenson]

​https://s3.amazonaws.com/eswenson-multics/public/mcrs/MCR10050.pdf

[Eric Swenson]

Milestone renamed