Maps

In systems like Multics [D1] and TENEX [T1], the implementation of a map is assisted by hardware. We had no such hardware. The map in CAL TSS actually consisted of swapping directives. When a subprocess was to run, it was copied from ECS to CM. Each swapping directive in the map specified some portion of some file (in ECS) to be copied into some part of CM. After running, each portion would be copied back to its ECS file. It should be understood that the maps in CAL TSS did not give the same facility as maps in other systems. For example, if the same portion of a file was mapped into different regions of CM, and the running program modified one of these CM regions, the modification was not immediately reflected in the other region, in contrast to systems like Multics or TENEX. In CAL TSS, the change would eventually appear after the subprocess was swapped out to ECS and back in to CM. In general, this was a fairly unpredictable occurrence. The problem was more severe than might be apparent. It is plausible to assume that a single subprocess would map a portion of a file into at most one region of CM. However, two subprocesses might independently map the same portion of a file. As we will indicate later, both subprocesses could be swapped into CM simultaneously. This would lead to precisely the problem described above. In fact, the disk-system (see Chapters 10 and 11) was composed of two subprocesses, and both mapped a common region of a scratch file. This indeed led to problems. The fix used was to explicitly read and write the common portion of the file, thus losing the automatic benefits of the map.